Comments on: xml:id

By: Anne

Anne — Thu, 10 Feb 2005 19:16:23 +0000

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

David Megginson — Thu, 10 Feb 2005 19:12:12 +0000

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

Anne — Thu, 10 Feb 2005 18:57:00 +0000

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

Oleg Tkachenko — Thu, 10 Feb 2005 18:32:51 +0000

Oops, I meant

By: Oleg Tkachenko

Oleg Tkachenko — Thu, 10 Feb 2005 18:30:33 +0000

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

Quoderat » Rumours of xml:id trouble in the W3C — Tue, 30 Nov -0001 00:00:00 +0000

[...] 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)

Quoderat » REST design question #5: the “C” word (content) — Tue, 30 Nov -0001 00:00:00 +0000

[...] 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 [...]