Re: id() doesn't work!?
Aaron Optimizer Digulla wrote: > Not having used xpointer to date, I don't know of the implications of it > and how hard it would be to solve the warning problem (maybe id() can > "throw an exception" somehow and xpointer() can discard it while the > normal use would display it or somesuch - I would have to look at the > sources to say that) but my guess is that it would be a simple thing > for you to do. When we were formulating XML, there was a lot of discussion of whether we should codify "id" and "idref" as the attributes for ids and references to them--the argument for was that it would avoid exactly the problem that we see with the id() function (and, by extension, bare names interpreted by the XPointer rules). The argument against was that it intruded on the document author's name space, a cardinal sin. I honestly don't remember which way I voted, but I probably voted against codifying "id" because I was, at the time, firmly steeped in the sanctity of the author's right to name. In hindsight, I think it was a mistake not to have codified "id" and "idref". The effect of the wide non-use of DTDs is that you are pretty much forced to either use "id" as the name of your ID attributes and use the "//*[@id='$name']" form of XPath or you must build into your style sheets complete knowledge of the identifying name spaces used for addressing. At the end of the day identification and referencing are application-level issues. A strong argument can be made that SGML should have never defined an ID mechanism at all--there are too many requirements it didn't meet and it only makes parsing and validation harder. [How many of you old SGML hands out there worked with or designed systems that defined all the ID attributes as "NAME" or "CDATA" because the business rules required repository-wide IDs or scoped ID uniqueness below the document level or need to solve the cross-document addressing requirements that SGML alone didn't satisfy?] If the Web has taught us anything it's that a few well-choosen and ubiquitous naming conventions can take you a long way. While I still believe strongly in the author's right to name, I no longer believe it is a right that outweighs all other considerations. I think that the problems raised by the ID attribute are a case in point--how much poorer would we be if "id" only and always meant "id" if it meant that the id() function always worked as expected? I have recently gone through similar but distinct exercises: implementing the XTM mergeMap element (in a Java processor [http://www.isogen.com/downloads]) and implementing as-complete-as-possible XPointer support using XSLT and EXSLT extensions [http://www.dpawson.co.uk/xsl/sect2/xpointer.html]. In the first case I map bare names in XPointers to "//*[@id='$name']" because the XTM spec defines the name of the ID attribute as "id", so users of my mergeMap resolver would expect bare names to *always* work, even though a strict implementation of XPointer would have them fail when there is no DTD (because bare names in XPointer map to id(), not //*[@id='$name']). Most, if not all, of the sample topic maps I've seen use bare names for in-document references, even when those documents do not have IDs--technically those documents should fail because XTM specifies XPointer and bare-name XPointers map to id(). But it would be what I call "Simon says" behavior to not go ahead and do what all the authors of those topic maps expect [If my mergeMap resolver refused to resolve bare names in the absence of a DTD it would be essentially saying "I didn't resolve those links because you didn't say 'Simon Says'--an unpardonable implementation sin in my book.] However, in my XPointer implementation, I cannot provide that natural fallback behavior. That means that lots of authors will have to rewrite their pointers from bare names to "//*[@id='name']" in order to make their documents work--that seems wrong and avoidable to me. But at the same time, the XPointer spec had little choice: it would be wrong for that spec to impose the name "id" on users (XML could do it because it's defining the markup language and individual document types can do it, but an after-the-fact support mechanism like XPointer cannot) and codifying even a standard fallback behavior would potentially lead to subtle, non-intuitive failures (or lack of failure when failure is expected) when 'id' was not in fact an ID attribute in a particular document. I think that the only answer to this problem is for the community of XML users to agree on a convention for IDs and pointers and for it to be codified in XML 2.0 or some such. I would be perfectly happy if "id" always meant "ID" and "href" always meant "URI-based pointer". I think the long-term benefit would far outweigh any cost in constrained naming choices. There will always be specifications like HyTime that provide for complete renaming of everything if you need to step up to that level of flexibilty. I think the current situation represents the worst compromise between ease of use and generality--it doesn't help in the case where you need a simple, consistent solution that is guaranteed to always work and it doesn't provide the flexibility you need because the cost of using it (requiring DTDs with instances) is too high. XLink exacerbates the problem by fixing the names of the referencing attributes (xlink:href), eliminating choice that might be useful in some cases (for example, in transparently mapping XHTML attributes to XLink semantics). I understand why the XLink committee was hesitant or unwilling to step up to a more general name mapping scheme--it leads to quite a bit of unavoidable complexity, but there are use cases for which it is the only viable solution. [And I remind this audience that the HyTime standard, ISO/IEC 10744:1997, still exists as one solution to the requirement to be able to do unconstrained name remapping if you need it--nobody buys a Swatch Car to haul furniture, but nobody buys a moving truck to commute day-to-day either.] Cheers, E. -- W. Eliot Kimber, eliot@xxxxxxxxxx Consultant, ISOGEN International 1016 La Posada Dr., Suite 240 Austin, TX 78752 Phone: 512.656.4139 XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
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