OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   basic xml philosophy question(s)

[ Lists Home | Date Index | Thread Index ]
  • From: "rsanford" <rsanford@nolimitsystems.com>
  • To: <xml-dev@xml.org>
  • Date: Thu, 15 Jun 2000 16:16:17 -0500

i'm not afraid of being a newbie and asking some basic
questions. i really want to understand what is considered
to be the best practices of just getting started. while
i find the high-order discussions of data interchange and
style sheet transformations to be interesting, they don't
help me get my data off of the wire and into objects that
i can manipulate.

i want to know, i want to learn. feed my hunger.


preview questions
do most of you out there use element-based or
attribute-based xml? why?

do most of you use event-based (sax, expat, etc)
or dom parsers? why?

do any of you use any additional parsing libraries to
make your lives easier? which ones? why or why not?

the meat
is it better to use element-based xml documents where an
element's "attributes" are expressed by sub-elements such

or attribute-based xml documents where an element's
attributes are expressed as xml attributes such as:
   <person lastName="bomb" firstName="duh"/>

the limited reading i have done seems to indicate that
the element-based approach is "better" but that is
primarily an impression and not based on anything more
significant than all examples being element-based.

however, writing automatic code generators that result
in a class hierarchy that contains:

is significantly easier in an attribute-based model.
when attempting to generate code in an element-based
model you would need to provide some sort of hint
mechanism to let the code generator know that the
last name should be easily accessible as an attribute
from the person element instead of having to write

this gets even trickier when trying to express a
psuedo-inheritance in xml where a programmer "is a"
person and a salesman also "is a" person (although
many will debate whether a salesman really is a person
or just a reptile in people skin we tend to represent
them as people when doing data modeling). i don't want
to have to worry about going through additional levels
of indirection when getting the last name of a programmer

i just want to say 

what's the best way to do this? is this even a desireable


This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS