tags:

views:

21

answers:

1

I'm creating an XML hierarchy that looks something like this:

element A
  0+ element B
    0+ element C (has PCDATA)
      (more complex hierarchy below this one, not really relevant)
  0+ element D
  0+ element E
  0+ element F
  0-1 element G (has PCDATA)
  0-1 element H (has PCDATA)

As a result, it's starting to look a little "crowded" under element A. Should I add container elements to organize things a bit, like so:

element A
  0-1 B-container
    0+ element B
      0-1 C-container
        0+ element C (has PCDATA)
          (more complex hierarchy below this one, not really relevant)
  0-1 D-container
    0+ element D
  0-1 E-container
    0+ element E
  0-1 F-container
    0+ element F
  0-1 element G (has PCDATA)
  0-1 element H (has PCDATA)

Or is it fine to have a bunch of different elements underneath element A?

This XML needs to be consumed by XSL stylesheets mostly written by users, so I'm trying to figure out what makes it easiest for users to interact with.

+1  A: 

I don't imagine it'll make that much of a difference to users who are creating stylesheets, any node can be selected using selectors either way - it'd just be different, not necessarily easier or harder.

I'd say it's more important to ensure that your data structure provides an intuitive representation of your data. If what you are representing is naturally hierarchical, go for a structure that represents it that way. Then, the structure will be easier to handle as it will be easier to remember and visualise, and nodes that would commonly be handled together will be close to each other in the tree.

Oh, and don't forget about attributes, either. One thing that bugs me sometimes when handling XML is data that feels naturally like an attribute - elements, for example.

Brabster
Thanks - I have a bunch of attributes used for data, the elements with PCDATA are only used when I have multiline text that needs to get output.
Colen