Lists Home |
Date Index |
- From: Edd Dumbill <firstname.lastname@example.org>
- To: "Simon St.Laurent" <email@example.com>
- Date: Sun, 29 Aug 1999 22:33:30 +0000
On Sun, Aug 29, 1999 at 12:26:09PM -0400, 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.
[ ... ]
> 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
> current system denies?
> 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.
I'm glad that you have raised this issue. It's been something that I've
noticed during my relatively limited time developing XML DTDs and tools
to support some of my projects (my limited experience should qualify my
The typical scenario would arise where I decided one piece of data ought
to be an attribute and then later discovered that I needed the
flexibility that came from being an element. Taking that experience to
an extreme would suggest that there is no need for attributes per se
other than their extremely useful shorthand.
It would seem that with the advent of schemas this case is strengthened.
One current advantage of attributes would be the extent to which you can
designate permissible values through the DTD, which is something you
can't really do for elements quite so tightly. But schemas would remove
The other change which provokes your question seems to be the growth in
use of XML for data-centric, rather than document-centric, applications
(by this I mean a move away from purely publishing and document centered
applications: the SGML heritage). It is simpler for programs and tools
to use one construct rather than two in composition of data types. It
also seems more "future-compatible": I cannot add complexity easily to
an attribute, yet I can do so to an element with some degree of control
over reverse compatibility of my XML documents.
I too have a fondness for attributes, but a nagging difficulty in
justifying them other than in situations where I am constructing my
documents "by hand".
Edd Dumbill ------/ a new media consultant, writer & technologist /--
| Director, Useful Information Company <http://usefulinc.com>
| Internet Director, Pharmalicensing <http://pharmalicensing.com>
: UK voice/msg: +44 702-093-6870 UK fax: +44 870-164-0230
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)