Elements Vs Attributes

I questioned.. (on xml-dev@lists.xml.org list)

I wrote earlier, that I would like to imagine elements as objects (as in OO programs) and attributes as object's properties. Is it right to think like this? So attribute ordering will not be the right concept.

The dictionary defines attribute as quality, characteristic, feature etc. An object's features (i.e. attributes) are just features. Giving an order to them doesn't seem right.

This also helps in deciding, what should be element and what should be attribute. Of course, at many places, elements can be made as attributes and attributes as elements (the XML parser allows to process the information depicted in either way). But what is making best sense in a given context, and problem domain, should be chosen (i.e. either elements or attributes).

Uche Ogbuji replied:

> I wrote earlier that, I would like to imagine elements as objects (as in OO programs) and attributes as
> object's properties.. Is it right to think like this?

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 [1] for discussion of confusion that arises from the fact that most "object references" in XML are implicit.

As for the specific question of XML versus attributes, I still think it's a weak approach. OO concerns such as identity and data typing which drive the matter in program modeling have poor natural correspondence in XML. I think you'd be fine with such an approach with trivial examples, but the elements/attributes choice is usually trivial, anyway, if the example is also trivial.

> So attribute ordering will not be the right concept.

Well, not so quickly. In OO, object references aren't ordered, either (you need to use an explicit vector to get order), so element ordering wouldn't be the right concept, either, if one were being so literal.

I think XML requires an entirely different mind-set from objects.

> The dictionary defines attribute as quality, characteristic, feature etc. An object's features
> (i.e. attributes) are just features! Giving an order to them doesn't seem right.

I also don't think this is fruitful territory. One could pick a dictionary definition of elements (e.g. the agents of weather) where order does matter, and one (e.g. the fundamental units of chemical compounds) where order does (at least in the sense of structuring in the periodic table). Again, I see nothing but misapprehension and confusion down this road.

Just as it's dangerous to do relational modeling in an OO mind-set, and vice versa (part of the reason those two worlds have so stubbornly resisted merging [2]), it's dangerous to do XML modeling in either mind-set, and so on.

[1] http://www-106.ibm.com/developerworks/xml/library/x-contain.html
[2] http://www.adtmag.com/article.asp?id=8596

see also debate of [2] at http://www.adtmag.com/article.asp?id=9090

I questioned further..

I would like to say a bit about this XML structure you have referred in your article:

<library>
    <name>The XML Institute Public Library</name>
    <books>
      <book isbn="0764547607">
        <title>The XML Bible, 2nd Edition</title>
      </book>
      <book isbn="0321150406">
        <title>Effective XML</title>
      </book>
      <book isbn="1861005946">
        <title>Beginning XSLT</title>
      </book>
    </books>
</library>

/library/books/book containership structure seems fine to me. name is a property of library (object), if we model a real world concept. It could have been made a attribute instead of element (to me, having it as attribute will match the real world view better). But here, I'll favor aesthetics than the OO thinking. To me, "name" as a child element of "library" appeals more aesthetically. It also seems more tool friendly (for e.g., 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 presence 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 artful activity, rather than being a pure science.

Uche Ogbuji replied:

I think that "name" is a far more important property than the artificial abstraction "books".  But in the end that's why I admit in 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 up different concerns from OO modeling.

> But here, I'll favor aesthetics than the OO thinking. To me, "name" as a child element of "library" appeals more aesthetically.
> It also seems more tool friendly (for e.g., 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 presence 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 artful activity, rather than being 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 different results.

Chris Burdess provided following information:

> 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.

You can't generalize it to all XML documents, no. But if you simply want to find an XML format that is capable of completely representing an existing object model, you might like to have a look at XMI:

http://www.omg.org/technology/documents/formal/xmi.htm

Home


Last Updated: Jul 11, 2009