[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Penance for misspent attributes
Hi Simon. "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) processes: 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 name/value pairs 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 assumptions: there is no atomic element molecular structures are abstractions which serve (and imply) processes 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. Respectfully, Walter Perry
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|