design pattern for nested xml?

[lawpoop]

I have two questions about the 'best' way to design an xml document.
The first is about tagging a collection of similar items as such, and
the other is about a nested structure.

I'm designing an app that can handle an arbitrary tree of a company's
organizational structure. Offices are actual physical locations, while
regions are nestable logical groupings of the offices.

When a region has office(s) as children, I've include the office tags
in <offices></offices>. However, I don't include nested regions in
<regions></regions> tags. Should I? Why or why not? I've noticed that
Michael Kay seems to always enclose repeating items in collection
tags, while other examples don't.

Here's an example.

<company>
<region>
<name>Northeast</name>
<region>
<name>New York</name>
<offices>
<office>
<name>New York Office</name>
<address>...</address>
</office>
<office>
<name>Albany</name>
<address>...</address>
<office>
</offices>
</region>
<region>
<name>Boston</name>
</region>
<region>
<name>Newark</name>
</region>
<region>
<name>Gulf Coast</name>
<region>
<name>Dallas</name>
</region>
<region>
<name>Dallas</name>
</region>
</region>
</company>

As far as my second question, if I should enclose any set of regions
in <regions></regions> tags, then shouldn't I include the entire tree
in <regions></regions> tags? In that case, couldn't I replace
<company>, or must the root node always be unique, even with nested
xmls?

 

[Andy Dingley]

I have two questions about the 'best' way to design an xml document.

For your example, I wouldn't use XML, I'd go straight to RDF, RDF
Schema and maybe even OWL.

Your offices aren't a "tree", they're a graph (mulltiple roots, not a
simple branching tree). XML is poor at these.

Your identifier structure is crucial to success here. Use URIs.

Typing (as practised by RDFS) would be extremely useful to you.

The downside of using RDF is that is does rather restrict the
implementation language to Java (or Scala, if you're fashionable!) as
that's where the good RDF toolsets are (start by looking at Jena).

 

[Martin Honnen]

I have two questions about the 'best' way to design an xml document.
The first is about tagging a collection of similar items as such, and
the other is about a nested structure.

I'm designing an app that can handle an arbitrary tree of a company's
organizational structure. Offices are actual physical locations, while
regions are nestable logical groupings of the offices.

When a region has office(s) as children, I've include the office tags
in <offices></offices>. However, I don't include nested regions in
<regions></regions> tags. Should I? Why or why not? I've noticed that
Michael Kay seems to always enclose repeating items in collection
tags, while other examples don't.

In my view you should at least be consistent in one XML document format
so use offices to wrap office elements and use regions to wrap region
elements or don't do it at all. Using one style for a part of the
document and a different for another is confusing.

Here's an example.

<company>
<region>
<name>Northeast</name>
<region>
<name>New York</name>
<offices>
<office>
<name>New York Office</name>
<address>...</address>
</office>
<office>
<name>Albany</name>
<address>...</address>
<office>
</offices>
</region>
<region>
<name>Boston</name>
</region>
<region>
<name>Newark</name>
</region>
<region>
<name>Gulf Coast</name>
<region>
<name>Dallas</name>
</region>
<region>
<name>Dallas</name>
</region>
</region>
</company>

As far as my second question, if I should enclose any set of regions
in <regions></regions> tags, then shouldn't I include the entire tree
in <regions></regions> tags? In that case, couldn't I replace
<company>, or must the root node always be unique, even with nested
xmls?

You need to have a single root element but the name does not have to be
unique.

 

[lawpoop]

In my view you should at least be consistent in one XML document format
so use offices to wrap office elements and use regions to wrap region
elements or don't do it at all. Using one style for a part of the
document and a different for another is confusing.

Martin, thanks for your perspective.

Does naming or not-naming collections have any arguments besides
consistency? For instance, say I want to do xslt with this xml.
Offices may or may not exist under a particular region. Would it be
any easier to check for offices as a collection or just looking for an
office.

 

[Martin Honnen]

Does naming or not-naming collections have any arguments besides
consistency? For instance, say I want to do xslt with this xml.
Offices may or may not exist under a particular region. Would it be
any easier to check for offices as a collection or just looking for an
office.

XSLT and XPath can access
offices/office
or
office
if a region element is the context node. That should not make a
difference in terms of XSLT/XPath.