Comments on: xml:id http://www.megginson.com/blogs/quoderat/2005/02/08/xmlid/ XML and the Web. Fri, 29 Aug 2008 03:59:53 +0000 http://wordpress.org/?v=2.5.1 By: Anne http://www.megginson.com/blogs/quoderat/2005/02/08/xmlid/#comment-59 Anne Thu, 10 Feb 2005 19:16:23 +0000 /?p=13#comment-59 Ah, thanks to "barenames" I found it. The official specification calls them <a href="http://www.w3.org/TR/2003/REC-xptr-framework-20030325/#shorthand">shorthand pointers</a> nowadays. Unfortunately the specification does not provide a simple example along with it. Ah, thanks to “barenames” I found it. The official specification calls them shorthand pointers nowadays. Unfortunately the specification does not provide a simple example along with it.

]]> By: David Megginson http://www.megginson.com/blogs/quoderat/2005/02/08/xmlid/#comment-58 David Megginson Thu, 10 Feb 2005 19:12:12 +0000 /?p=13#comment-58 Anne and Oleg are both correct, as far as I understand the specs. In the general case, like in the toolbar of a browser, it's not safe to assume that a bare name in a fragment identifier has any special meaning, like Oleg says; however, the XLink spec states that the fragment identifier in the value of the xlink:href attribute is an XPointer, and the XPointer spec states that a bare name is an ID (and explicitly mentions the application/xml MIME type), like Anne says. I didn't explicitly mention XLink and XPointer in the original posting, so here's an example that (I think) is correct, assuming that the <em>xlink</em> prefix is already declared on an ancestor element: <code><employee-ref xlink:type="simple" xlink:href="http://www.example.org/employees.xml#dmeg123"/></code> I'll be glad when we don't have to include <em>xlink:type</em> any more. Anne: <a href="http://www.w3.org/TR/WD-xptr#bare-names">here's</a> where the XPointer spec defines bare names. Anne and Oleg are both correct, as far as I understand the specs. In the general case, like in the toolbar of a browser, it’s not safe to assume that a bare name in a fragment identifier has any special meaning, like Oleg says; however, the XLink spec states that the fragment identifier in the value of the xlink:href attribute is an XPointer, and the XPointer spec states that a bare name is an ID (and explicitly mentions the application/xml MIME type), like Anne says.

I didn’t explicitly mention XLink and XPointer in the original posting, so here’s an example that (I think) is correct, assuming that the xlink prefix is already declared on an ancestor element:

<employee-ref xlink:type="simple" xlink:href="http://www.example.org/employees.xml#dmeg123"/>

I’ll be glad when we don’t have to include xlink:type any more. Anne: here’s where the XPointer spec defines bare names.

]]> By: Anne http://www.megginson.com/blogs/quoderat/2005/02/08/xmlid/#comment-56 Anne Thu, 10 Feb 2005 18:57:00 +0000 /?p=13#comment-56 I always thought that #foo was short for XPointer #xpointer(id('foo')) in XML context. However, I can not find it in the XPointer specification. I always thought that #foo was short for XPointer #xpointer(id(’foo’)) in XML context. However, I can not find it in the XPointer specification.

]]> By: Oleg Tkachenko http://www.megginson.com/blogs/quoderat/2005/02/08/xmlid/#comment-55 Oleg Tkachenko Thu, 10 Feb 2005 18:32:51 +0000 /?p=13#comment-55 Oops, I meant <xi:include href="http://www.example.org/employees.xml" xpointer="dmeg123"/> Oops, I meant
<xi:include href=”http://www.example.org/employees.xml” xpointer=”dmeg123″/>

]]> By: Oleg Tkachenko http://www.megginson.com/blogs/quoderat/2005/02/08/xmlid/#comment-54 Oleg Tkachenko Thu, 10 Feb 2005 18:30:33 +0000 /?p=13#comment-54 A bit of nitpicking: I'd say http://www.example.org/employees.xml#dmeg123 is bad example here. As per "Architecture of the World Wide Web": "When the media type assigned to representation data is "application/xml", there are no semantics defined for fragment identifiers, and authors should not make use of fragment identifiers in such data. The same is true if the assigned media type has the suffix "+xml" (defined in "XML Media Types" [RFC3023]), and the data format specification does not specify fragment identifier semantics. In short, just knowing that content is XML does not provide information about fragment identifier semantics. Many people assume that the fragment identifier #abc, when referring to XML data, identifies the element in the document with the ID "abc". However, there is no normative support for this assumption. A revision of RFC 3023 is expected to address this." In XInclude it would be <xi :include href="http://www.example.org/employees.xml" xpointer="dmeg123"/></xi> A bit of nitpicking: I’d say http://www.example.org/employees.xml#dmeg123 is bad example here.
As per “Architecture of the World Wide Web”:
“When the media type assigned to representation data is “application/xml”, there are no semantics defined for fragment identifiers, and authors should not make use of fragment identifiers in such data. The same is true if the assigned media type has the suffix “+xml” (defined in “XML Media Types” [RFC3023]), and the data format specification does not specify fragment identifier semantics. In short, just knowing that content is XML does not provide information about fragment identifier semantics.

Many people assume that the fragment identifier #abc, when referring to XML data, identifies the element in the document with the ID “abc”. However, there is no normative support for this assumption. A revision of RFC 3023 is expected to address this.”

In XInclude it would be

]]> By: Quoderat » Rumours of xml:id trouble in the W3C http://www.megginson.com/blogs/quoderat/2005/02/08/xmlid/#comment-62 Quoderat » Rumours of xml:id trouble in the W3C Tue, 30 Nov 1999 00:00:00 +0000 /?p=13#comment-62 [...] xml:id specification (released only days ago as a Candidate Recommendation, as I mentioned <a href="http://www.megginson.com/blogs/quoderat/archives/2005/02/08/xmlid/">here</a>) – there is some other specification (not named) that has a bug, mo [...] [...] xml:id specification (released only days ago as a Candidate Recommendation, as I mentioned here) – there is some other specification (not named) that has a bug, mo [...]

]]> By: Quoderat » REST design question #5: the “C” word (content) http://www.megginson.com/blogs/quoderat/2005/02/08/xmlid/#comment-155 Quoderat » REST design question #5: the “C” word (content) Tue, 30 Nov 1999 00:00:00 +0000 /?p=13#comment-155 [...] ml:id can allow links to point to fragments of XML documents easily, making it possible to <a href="http://www.megginson.com/blogs/quoderat/archives/2005/02/08/xmlid/">refer to embedded resources</a>. <data> <person xml:id="dpm"> <na [...] [...] ml:id can allow links to point to fragments of XML documents easily, making it possible to refer to embedded resources. <data> <person xml:id=”dpm”> <na [...]

]]>