W3C home > Mailing lists > Public > www-tag@w3.org > September 2002

Re: two failings of XLink

From: Simon St.Laurent <simonstl@simonstl.com>
Date: Thu, 26 Sep 2002 15:58:32 -0400
To: www-tag@w3.org
Message-ID: <r01050300-1015-5599D27ED18A11D68A750003937A08C2@[]>

Elliotte Rusty Harold writes:
> That's OK with me. One empty-element tag per link required. I see no 
> problem with this whatsoever. It's *marginally* more verbose than the 
> current syntax. However, it's also more extensible and cleaner. Early 
> HTML tried to put way too much into attributes.

I'm still not quite sure why you started out by saying:
> There is no one-URI per element rule in XLink. there is a one-URI per 
> tag rule. That'sa very different thing.

In general, though, I've found (X)HTML's element/attribute balance
pretty simple to figure out.  Mark up the text with elements, add
metadata about how those attributes work with attributes, and use
occasional empty elements for content in a very few difficult cases.  

(The only markup I've ever found annoying in (X)HTML is the stuff in the
HEAD element, which often looks to me like some programmer stuffed
objects into quick HTML syntax without thinking too hard about it.)

To continue:
> One thing I've learned in XML-land is that if there's any doubt about 
> whether something should be an attribute or an element, it's almost 
> always better off as an element, and much of the time when there's no 
> doubt that something needs to be an attribute, it's still turns out 
> to be better off as an element in the long run.

I share the same general bias, but I'm far from convinced that every URI
deserves a home in its own element as a matter of principle.  

Simon St.Laurent - SSL is my TLA
http://simonstl.com may be my URI
http://monasticxml.org may be my ascetic URI
urn:oid: is another possibility altogether
Received on Thursday, 26 September 2002 15:58:33 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:34 UTC