Merrill, Jason wrote:
It's well formed, sure, but I would do it like this instead - make heavy
use of attributes - as much as possible for speed, relationships, and
readability, something like this:
Preferrably if you could find a way to work this, you could also maybe
just do this to reduce redundancy:
<root>
<clients>
<client name="Borgo di Colleoli" sector="Property">
<discipline name="Direct Mail"/>
<discipline name="Advertising"/>
</client>
<client name="Royal Bank of Scotland" sector="Finance">
<discipline name="Interactive Design"/>
<discipline name="Strategy"/>
</client>
</clients>
..add more here
</root>
...and then make some use of XPath's search features to find the
opposite relationships - i.e. sector to client, discipline to sector,
etc. - though I haven't used it yet so wouldn't have an example to share
Thanks for that. Unfortunately I don't think I'm going to be able to use
attributes for anything more than names, because a client may exist inside
multiple sectors I believe.
I was hoping I could cut down on the redundancy, so I'll certainly look into
traversing the tree in both directions with XPath.
I did wonder if using attributes more than text inside nodes made more sense
After reading this article, I'm confused why client name does not merit an
element?
I don't know the rules - or even if there ARE rules - but my reasoning was that
the name attribute was part of the client, but the others were separate but
belonged to the client. Just my logic.
Another question, would I be better off parsing all my relationships into
associative arrays (like they are hardcoded now) on start up, or is XPath quick
enough that I could read it directly each time?
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
