Embedding Content as Element Content or As An Attribute Value

[Paul Prescod]

Michael Kay wrote:
> 
> I think Marcus is wrong. The domain of application of SGML is different 
> from the domain of application of XML, and the distinction between 
> attributes and content which made sense in the SGML world is extremely 
> perplexing to those with a background in data modelling and data 
> structure design in other domains, who are legitimate members of
> the XML community. Philosophically - at least in terms of any 
> ontological system I am aware of it is a nonsense, and can be 
> justified only in terms of pragmatic assumptions about information in 
> the form of paper documents.

The elements and attributes distinction is indeed driven by pragmatics,
but those pragmatics have nothing to do with print. Members of the
database community have asked us to strengthen the expressive power of
attributes so that they can be used to more accurately model attribute
of an object in an OOP system.

I'm surprised, though that you would claim that the distinction between
"hasproperty" and "containsobject" is missing in every ontological
system you are aware of. Clearly attributes can be used to model that
distinction (for applications where it is relevant).

Anyhow, I'm curious why you think that the domain of XML is that
different from SGML. XML is SGML for the Web.
 
> In the DTD I've been designing, for what it's worth, I'm currently 
> using content for nearly everything, with very little use of 
> attributes. The main reason is for future extensibility;
> elements can always acquire a richer internal structure, while 
> attributes can't. The drawbacks (e.g. inability to specify any 
> constraints on values, default values, etc) don't actually lose me much, 
> because the constraints available for attributes are very limited anyway.

You've missed the point that attributes have an important feature w.r.t
extensibility. An unknown attribute just disappears in processing, since
they are named by role. In every XML/SGML processing system I am aware
of (including XML DTDs, DSSSL, XSL and probably SAX), it is harder to
handle unknown elements because their GI could represent either their
role or their object type. If it is an unknown role, it is probably safe
to ignore them, but if it is an unknown object type "filling in for"
another object type in the same role, then you should flag an error or
lookup a handler or do something else. 

<BIBLIO>
	<NAME>...</NAME>
	<DATE>...</DATE>
</BIBLIO>

I can add a role without harming anything:

<BIBLIO>
	<NAME>...</NAME>
	<DATE>...</DATE>
	<URL>...</URL>
</BIBLIO>

Older processing software can safely ignore URLs.

But if I change an object type things break:

<BIBLIO>
	<NAME>...</NAME>
	<ISODATE>...</ISODATE>
	<URL>...</URL>
</BIBLIO>

How do I now process this? The old software depended on the DATE being
available.

What the database people have asked for (and what I also want) is the
ability to have attributes which retain their distinction between role
and type, but also can have tree internal structure. This gives us the
best of both worlds, as well as the ability to choose elements or
attributes based on ontological systems and not pragmatics.

 Paul Prescod
--
http://itrc.uwaterloo.ca/~papresco

Art is always at peril in universities, where there are so many people, 
young and old, who love art less than argument, and dote upon a text 
that provides the nutritious pemmican on which scholars love to chew. 
				-- Robertson Davies in "The Cunning Man"


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)