This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
In the XSLT 2.0 Working Draft 4 April 2005, http://www.w3.org/TR/2005/WD-xslt20-20050404/, the Note paragraph in section "3.11 Embedded Stylesheet Modules" says the following: "In order for such an attribute to be used with the XPath idFO function, it must actually be declared in the DTD or schema as being of type ID. The same requirement typically applies if the identifier is to be used as a fragment identifier in a URI reference." According to my knowledge an attribute must be typed to be of type ID. The paragraphs says that the type information MUST be supplied via a DTD or schema. However, according to my knowledge there is another mechanism for adding ID type information: xml:id. In the similar vene, from what I know one could argue that a DTD is a particular type of schema. In order to not constrain the user's possibilities and be open to future developments in the typing-area, it might be of interest to phrase the paragraph more generically, to only dictate that the attribute needs to be of type ID, and to give DTD as an /example/ of how to express that type information. According to my interpretation, it would be normatively wrong to accepttype information expressed via xml:id. However, considering the controversies over xml:id, this is perhaps intentional. Cheers, Frans Frans Englich KDE Developer
Thanks for the comment. We should really change this from saying the attribute must be of type ID to saying that the is-id property in the data model must be set. (The existing text seems to be unchanged since 1.0). (This property is automatically set for the xml:id attribute; but this note is only talking about the id attribute). The other oddity about this paragraph is the reference to the id() function. In the context of embedded stylesheet modules, what users really want to know is whether they can use the id value as a fragment identifier, not whether they can use it in a call to the id() function. I suspect the 1.0 text avoiding discussing this because the meaning of a fragment identifier technically depends on the media type of the document containing the embedded stylesheet, and as far as I know we *still* don't have an official spec that says bare ID values are legitimate as fragment identfiers for the application/XML media type. If the problem were confined to changing the note to permit identification using xml:id, I would treat it as editorial, but because of the interaction with media types, I think the comment probably needs WG discussion. Michael Kay
(In reply to comment #1) > use it in a call to the id() function. I suspect the 1.0 text avoiding > discussing this because the meaning of a fragment identifier technically depends > on the media type of the document containing the embedded stylesheet, and as far > as I know we *still* don't have an official spec that says bare ID values are > legitimate as fragment identfiers for the application/XML media type. > Well, it's, let us say, open to debate. The official spec is still RFC 3023, which says: "As of today no established specifications define identifiers for XML media types." But then goes on to talk about XPointer, which was not (then) a Recommendation. ("Today" was January 2001) Now the XPointer framework DOES say bare ID values are legitimate fragment identifiers, and it's a W3C recommendation. I thought about this for a long time, before deciding that this DOES legitmise bare IDs, but as I could see some people might not be 100% convinced by my reasoning, for my own XSLT processor, I have made it an option (by default, use of XPointer is assumed legitimate, but if the user feels strongly enough about it, (s)he can turn it off). this seemed to be the best practical approach.
A revised version of 3023 is in the works and I fully expect it to endorse #foo as a legitimate fragment identifier for locating <elem xml:id="foo"/> in any document of type /xml or /*+xml.
We decided to make two changes: (a) instead of saying the attribute must be "of type ID", we will say that the attribute node must have the is-ID property defined in the data model (with some words of explanation). (b) we will remove the reference to the id() function, and instead refer to the use of identifiers in URI fragment identifiers, mentioning that support for this is widespread in existing products and is expected to be endorsed in a future revision of RFC 3023. I will close this bug in the hope that you find this resolution satisfactory; if not, please feel free to reopen it. Michael Kay for the XSL Working Group