[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
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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|