xml-dev - Re: Element/Attribute Distinction Considered Harmful]

[Philip Nye <philipnye@freenet.co.uk>]

I thoroughly agree with you (Paul Prescod's proposals for attr+ were
working this way), but it seems just daft to pick whether to use an
attribute or an element based on whether you want to to be able to
specify a default (or enumerated values) or whether you want to have
order defined and use Xlink to point to it. I find I shuttle back and
forth between attribute and element use madly purely because of such
arbitrary choices.

It would seem easy enough to add default values and even enumerated
values to elements in schemas but the order question means that the &
operator raises its ugly head again. (see Paul Prescod's recent proposal
on this as well). Apart from these purely pragmatic differences, I think
that any semantic distinction between elements and attributes (in XML
rather than in specific document types) is an illusion.

Philip Nye
Engineering Arts

---- Original Message -------------------------------------
"Simon St.Laurent" wrote:
> 
> After writing the usual 'when to use elements and when to use attributes' bit
> for a new book and then spending some time close up with the XLink specs, I'm
> really starting to wonder if we haven't painted ourselves into a corner by
> treating leaf elements and attributes differently.
> 
> I'm not complaining about notation - in fact, I'm quite fond of attributes as
> an abbreviated form that makes clearer (at times) that given information is
> perhaps annotation for another component rather than a component of its own.
> 
> My concerns arise more with schema development and attribute usage in
> situations like XLink.  By using tools that require a given piece of
> information to appear as an attribute, we gain the use of one set of tools
> (defaulting and somewhat better restraints) at the cost of another set of
> tools
> (the ability to annotate that information itself, or to plain old store
> multiple levels of information, plus the ever-lingering question of whether
> attribute sequence matters.)
> 
> For a simple example, I'll use the HTML 4.0 IMG element and three of its
> attributes: SRC, LONGDESC, and USEMAP.  All three of them take URIs for
> values:
> <!ATTLIST IMG
>         SRC             CDATA   #REQUIRED
>         LONGDESC        CDATA   #IMPLIED
>         USEMAP          CDATA   #IMPLIED>
> 
> (In the HTML 4.01 spec, they use %uri; for the content model, which
> resolves to
> CDATA.  They also use lower case.)
> 
> All three of these attributes are locators - they carry URIs that can be used
> to retrieve additional information about the image.  SRC is the 'primary'
> attribute, without which there isn't an image, while LONGDESC provides a link
> to extra description of the image and USEMAP points to an image map resolver,
> itself another set of links.
> 
> Because XLink follows the current expectations of schemas, and because XLink
> relies on the element/attribute distinction for its understanding of which
> containers hold link-relevant information, XLink cannot support this use case
> directly.  _If_ IMG stored SRC, LONGDESC, and USEMAP as child elements, XLink
> could support this easily.  However, XLink provides no support for 'extended
> links' where all the linking information is presented as attributes rather
> than
> child elements.  In the current usage of XML and schemas, it has no formal
> vocabulary available to it that lets it handle this case.
> 
> Another case that's generated some (reasonably violent) comment is the use of
> the style attribute in HTML for use with CSS.  In HTML, you can do inline
> styling by attaching a style attribute to the element to be styled.  That
> single attribute may hold hundreds of different style properties, using a
> commonly understood convention.  For example,
> 
> <P style="font-size:18pt; font-weight:bold; color:42426F;
> font-family:sans-serif">This is my crazy paragraph!</P>
> 
> The style attribute here stores four name-value pairs, violating quite
> thoroughly the principle that an attribute represents a single value and
> irritating some folks enormously.  The same information could have been
> represented as:
> 
> <P>
> <style font-size="18pt" font-weight="bold" color="42426F"
> font-family="sans-serif" />This is my crazy paragraph!</P>
> 
> or even:
> <P>
> <style>
>         <font-size>18pt</font-size>
>        <font-weight>bold</font-weight>
>        <color>42426F</color>
>        <font-family>sans-serif</font-family>
> </style>
> This is my crazy paragraph!</P>
> 
> You get the idea...
> 
> It seems like child elements and attributes are both basically name-value
> pairs.  In the case of child elements, we treat order as important, while in
> the case of attributes it's considered unclear.
> 
> Apart from being the status quo, does this approach really make sense?  Am I
> the only one wondering if maybe it's time to start breaking down this
> distinction - at least within schemas - to give XML some of the flexibility
> the
> current system denies?  (RDF certainly took that approach, but wrapped it in
> lots of alien - to XML - concepts that I think obscured its value.)  It's
> taken
> me a long time to reach these conclusions - until recently, I really liked
> that
> status quo, though without much good cause.
> 
> I'd love to hear people's opinions on this subject, if indeed anyone else
> considers it worth addressing.  It has immediate impact on developments like
> schemas, as well as significant implications for XLink and potentially CSS
> style application.
> 
> Simon St.Laurent
> XML: A Primer (2nd Ed - September)
> Building XML Applications
> Inside XML DTDs: Scientific and Technical
> Sharing Bandwidth / Cookies
> http://www.simonstl.com
> 
> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
> Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
> To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
> (un)subscribe xml-dev
> To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
> subscribe xml-dev-digest
> List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)