[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: IDs considered harmful or why keys might be better than ID


xml and ids
Eric,

>
> Yes, and I have been provocative on purpose... This is, nevertheless,
> not completely pointless and the fact to provide a "hardwired" IDs will
> push many people who would otherwise have needed to be more creative
> into using these IDs.
>
>

Of course it is implicit that you are being provocative on purpose :-))

Likewise we can make the point that there is a distinction between an XML
_structure_, e.g. element, attribute, fragment and what a particular
application considers an _object_. Certain applications such as HTML
browsers may have standardized objects (e.g. DOM) and other applications may
use XML to serialize their own objects, but we need to distinguish between
this XML and the application object. Perhaps this is the point you are
making and if so I agree.

> >
> > Fragment identifiers of URIs are intended to be parsed according to
media
> > type (perhaps application/xml) and as such the idea that there is an
"XML
> > name" for a fragment of a document is a completely valid one, of course
> > realizing that other applications may choose to name things in different
> > ways. For example XSLT keys or XML Schema keys, the point being that if
the
> > HTTP server returns the document of media type application/xml, that the
> > fragment identifier will have a consistent interpretation. It is
important
> > to start with this as a basis.
>
>
> But, the basis that will be chosen will be more or less extensible.
>
> Using "xml:id" is probably the less extensible basis (even less
> extensible than DTD's IDs were).
>
> {http://purl.org/xmlid}:id is hardly more extensible and the first
> solution which IMO gives it some flexibility is James Clark's xml:idatt.

Of course but we _already have_ a more extensible mechanism for defining ids
and keys, namely the DTD and XML Schema. As I've said, one can do all this
in XML 1.0 using an internal subset, so I am not sure that we really need a
_more_ robust solution -- then we will simply have yet another robust soluti
on.

The only reason that I see the need for something really lightweight like
"xml:id" is that internal subsets are not well handled by common software
(e.g. SAX), but I don't think that is the fault of XML 1.0, rather by the
assumption that not everything is important, i.e. a _Simple_ API for XML is
fine and good until you need to do something slightly complex.

>
> The keys which I was thinking of could follow the syntax defined by XSLT
> and be defined either:
>
> 1) In the document:
>
> <foo><xxx:key
>    name = qname
>    match = pattern
>    use = expression />
> </foo>
>
> 2) Linked from the document:
>
> <foo><xxx:key-ref
>    xlink:href="mykey.xml"
>    xlink:type="simple"/>
> </foo>
>
> 3) Defined in the URL
>
> In the first 2 cases, this would be the usual http://foo.xml#bar, but
>
> http://foo.xml#key(http://mykey.xml,bar)
>
> with the same tricks than XPointer is using to declare namespaces URIs
> could be used to point on another key.
>

Certainly, but why stop here! Why not go all out and allow inline XML Schema
syntax. Similarly XPointer defines 3 forms, including raw names which
presumably point to xml:id like attributes. The full xpointer syntax
includes XPath so complex "keys" can indeed be already built from the
current proposal.

What I wish to avoid is having 5 different ways to do _everything_ because
that needlessly complicates XML.

Jonathan



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.