xml-dev - Re: basic xml philosophy question(s)

["Mike Sharp" <msharp@lante.com>]

I'll take a stab, and throw out my 2 cents...

While I wholeheartedly agree there is no "right" way, there _is_ a way that I
prefer.  I used to pack the element with attributes, but now that I'm living in
an OO world, I tend to use attributes for infomation that describes the content
of the element.  For example, I would say:

<programmers type="collect">
     <programmer>
          <firstName>Mike</firstName>
          <lastName>Sharp</lastName>
          <employeeID readOnly="true">12345</employeeID>
     <programmer>
     <programmer>
          <firstName>Clark</firstName>
          <lastName>Kent</lastName>
          <employeeID readOnly="true">67890</employeeID>
     <programmer>
</programmers>

I find that the attributes are a convenient way for the middleware guy to
communicate to me (the UI developer) metadata about the content.  Then I add my
own attributes, such as:
          <firstName isDirty="true">Michael</firstName>
which I use in this case to track whether a value has been changed by the user.

Other ways we use attributes are in a special case where I want to include
information about the Parent of an object.  In the above example, lets say I
want to include the company division of the programmer.  I would then expect the
following from my middleware:
     <programmer>
          <firstName>Mike</firstName>
          <lastName>Sharp</lastName>
          <employeeID readOnly="true">12345</employeeID>
          <companyDivision id="ab456-536e6-f21456">Internet Product
Group</companyDivision>
     <programmer>

Notice the difference between the employeeID and the companyDivision id.  For
the companyDivision, "id" is the foreign key attribute from the database table,
that points to the parent.  The code generator looks for such foreign keys, and
treats them all the same way.  But the employeeID is actually just a field in
the programmer table, not a foreign key, so it isn't any different (from my
point of view) than the firstName, even though it is probably the primary key to
the programmer.

The trick is, as others have stated, is to use whatever method is appropriate to
your needs.  The fellow that developed our middleware doesn't seem to have a
problem with this approach--in fact, this _is_ his approach.  His code generator
has only one class for generating and setting XML streams, so the Programmer
Object and its children and parent always follow the same structure, as any
other object and it's children and parent.  But you could do the same thing with
a different structure.  As long as you're consistent, you should be able to
write a code generator for either case.

regards,
Mike Sharp

Senior Site Developer
Lante Corporation

-----------------------
Give a man a fish and he will eat for a day. Teach him how to fish, and he will
sit in a boat and drink beer all day.    -- KPIG






"rsanford" <rsanford@nolimitsystems.com> on 06/15/2000 02:16:17 PM

To:   xml-dev@xml.org
cc:    (bcc: Mike Sharp/Lante)

Subject:  basic xml philosophy question(s)




---------------
the meat
---------------
is it better to use element-based xml documents where an
element's "attributes" are expressed by sub-elements such
as:
   <person>
      <lastName>bomb</lastName>
      <firstName>duh</firstName>
   </person>

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:
   person.getLastName();

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
   person.getLastName().getElementValue();

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
via:
   prgrammer.getPerson().getLastName().getElementValue();

i just want to say
   programmer.getLastName();

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

rjsjr








..................................
http://www.lante.com



***************************************************************************
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/
***************************************************************************