Re: Distinguishing Attributes and Content

> A little intellectual sleight of hand could be useful here.  It is easy enough
> to look at PCDATA as an empty element with a single _data_ attribute, i.e.
> <element-with-data>Here's some data</element-with-data> ==
> <element-with-data><pcdata data = "Here's some data"/></element-with-data>
> This makes the document data attributes of the pcdata elements.  If the parent
> element doesn't have mixed content we can hoist the content:
> <element-with-data data = "Here's some data"/>.
> 
> The implication of this little trick is that data and attributes are leaves of
> the document tree and therefore shouldn't have any structure (data being just a
> privileged attribute).  

I see some (small? you decide) problems:

#1. Aren't empty elements also leaves? If all leaves are attributes, then 
    empty elements (e.g. <BR>) are "really" attributes. 

#2. As we discussed in the fall, if you think of character data as an element,
    you add an extra level to the grove. element-with-data has <pcdata> as a
child which has "data" as an attribute. The mythical <pcdata> element is a 
peer to elements we would consider "embedded" in the text (e.g. a <BR>) 
But the "traditional" SGML grove has each character as a peer node with
elements buried in it.

#3. "data" isn't a privileged attribute: its an unpriviledged one. Why can't
I express an attribute type for data? Why can't I express a default value for
it?

If you turn the problem around, the language should STILL be more regular in
its treatment of attributes and data.

*But* I **do not think that this should be corrected in XML**. We don't have
time, we don't have all of the right people here to discuss it, we can't 
create something incompatible with SGML, etc.  There will be an XML 2.0. 

 Paul Prescod

Received on Tuesday, 20 May 1997 13:44:03 UTC