Lists Home |
Date Index |
On Sun, 2005-05-08 at 09:25 -0700, Mukul Gandhi wrote:
> --- Uche Ogbuji <firstname.lastname@example.org> wrote:
> > It can be very dangerous thinking overall. I've
> > seen numerous examples
> > of poor XML design because of too literal a
> > translation from OO
> > concepts. Just for one example, see  for
> > discussion of confusion
> > that arises from the fact that most "object
> > references" in XML are
> > implicit.
> Now I realize, that mapping XML model(using element
> containership and attributes) to OO paradigm is not
> quite appropriate.. For trivial examples, we may do
> so. But we cannot generalize this correspondence.
> . I
> read your article . Really a nice article.
> You have
> given an example to model a library inventory with
> XML.. I would like to say a bit about this XML
> structure you gave -
> <name>The XML Institute Public Library</name>
> <book isbn="0764547607">
> <title>The XML Bible, 2nd Edition</title>
> <book isbn="0321150406">
> <title>Effective XML</title>
> <book isbn="1861005946">
> <title>Beginning XSLT</title>
> /library/books/book containership structure seems fine
> to me. name is a property of library (object), if we
> model a real world concept.
I think that "name" is a far more important propoerty than the
artificial abstraction "books". But in the end that's why I admit int
the article it's a matter of judgment.
> . It could have been made a
> attribute instead of element (to me, having it as
> attribute will match the real world view better).
I think that's a bad idea for a couple of reasons:
1) It's really meant for people, not machines. I prefer to use
attributes for metadata-like things with affinity towards machines
2) It forbids internal structure. If after the initial design, it turns
out there is a library within whose name we really want to use
underlines/italics or such, we have to resort to hacks.
I almost always put names and titles in elements, rather than
attributes, for reasons I elaborate on in several of the articles in the
Principles of XML series.
Again, this is a good example of how XML modeling brings uo different
concerns from OO modeling.
> here, I'll favour aesthetics than the OO thinking.. To
> me, "name" as a child element of "library" appeals
> more aesthetically. It also seems more tool friendly
> (like to an XML editor).. For e.g. if a description
> becomes too long (e.g. name) , making it an attribute
> is not quite readable. Also if there are chances of
> existence of newline in data, I'll prefer to make the
> information as element..
> So it seems to me now, that designing an XML document
> is also an art, than a pure science..
Of course it's an art. But to be fair, so is OO modeling. Science is
deterministic, but if you put 5 OO experts in 5 different rooms with the
same problem and had them come up with an OO design, you'd get 5
> > I think XML requires an entirely different mind-set
> > from objects.
> Yes.. Now I realize!
Yaaaay! I do think that's a very important point of view to come to. I
also came to XML from OO, and I still work in OO, and I've learned to
separate the two, to the benefit of both.
> I read your artcile  also.. Its nice too!
> >  http://www-106.ibm.com/developerworks/xml/library/x-contain.html
> >  http://www.adtmag.com/article.asp?id=8596
Uche Ogbuji Fourthought, Inc.
Use CSS to display XML, part 2 - http://www-128.ibm.com/developerworks/edu/x-dw-x-xmlcss2-i.html
XML Output with 4Suite & Amara - http://www.xml.com/pub/a/2005/04/20/py-xml.html
Use XSLT to prepare XML for import into OpenOffice Calc - http://www.ibm.com/developerworks/xml/library/x-oocalc/
Schema standardization for top-down semantic transparency - http://www-128.ibm.com/developerworks/xml/library/x-think31.html