Lists Home |
Date Index |
"Simon St.Laurent" wrote:
> It's striking me more and more that developers, myself included, have done
> a poor job of examining and explaining how markup works and what the parts
> do best. That extends to a key discussion which is generally considered
> dull but radioactive: the elements/attributes distinction.
> A lot of people have been storing data in attributes rather than in
> element content. There are lot of reasons for this, ranging from a more
> compact form to simpler processing in SAX. (Attributes are presented as a
> convenient group, while you have to wait for child elements)
This was the very presentation that I gave to the XML SIG last month. The
argument goes like this:
I). The 'semantic' view is that XML is
a hierarchical tree structure
realization of infoset nodes
serialization of a document object.
The 'syntactic' view is that XML is
content plus markup
requires process to render or otherwise realize
process acts upon syntax (lexical content).
II). Taking the syntactic view, there are two natural (and necessary)
Linking (Name/Value Table Joins)
Data Structure Matching (adjustment of granularity)
In XML, the first is native to attributes, the second to elements.
III). Attributes are
equivalent to table name plus foreign key
may inherently be processed as links
can form a chain of joined relations
should be the basis of aliasing, set identity, and reference lookups
Elements, however, are inherently autonomous both as to structure and
content, neither of which is altered by the operation of attribute (linking)
processes against those elements. E.g. namespaces disambiguate elements by
aliasing, but as an attribute process that namespacing says nothing of the
structural context nor of the content model of the element.
IV). The native processing of elements is the adjustment of there
granularity, in order to map them to or measure their congruence with other
element (structures). The nature of this element processing is based on the
there is no atomic element
molecular structures are abstractions which serve (and imply)
granularity is infinitely adjustable in the markup.
We can take either a top-down or a bottom-up view of 'natural' element
processing. In the top-down view, data, consisting of element structure plus
content, is created to the expectations expressed (hard-coded!) in a
process. In the bottom-up view, the structure of the instance data must be
adjusted at each manipulation to the expectations of the process. In the
processing of elements, 'meaning' is conveyed in the instance through the
structural context of each element, but is only elaborated as specific
semantics through the operation of a process against the element syntax.
Static or asserted semantics may be conveyed for elements by attribute
processes (specifically joins and aliases, which are the same thing), but
those are the metadata semantics about the element, not the semantics of the
element itself (just as I understand Simon to argue). Notice,
parenthetically, in all this that datatype, if it is a concern at all, is a
concern of the process, predicated on the nature of the data which it
requires, and not at all a concern of the instance document.