W3C home > Mailing lists > Public > www-tag@w3.org > October 2010

Re: Generic processing of Fragment IDs in RFC 3023bis

From: Graham Klyne <GK-lists@ninebynine.org>
Date: Thu, 07 Oct 2010 15:38:57 +0100
Message-ID: <4CADDB81.4050301@ninebynine.org>
To: Jonathan Rees <jar@creativecommons.org>
CC: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, "Roy T. Fielding" <fielding@gbiv.com>, Noah Mendelsohn <nrm@arcanedomain.com>, Norman Walsh <ndw@nwalsh.com>, www-tag@w3.org
Jonathan Rees wrote:
> My scenario was constructed to exaggerate the problem. In the example
> we have XML resolution giving one element, and RDF resolution giving
> another. This is purely hypothetical, but is consistent with RDF's
> design (inference over *arbitrary* domains - including the domain of
> XML elements) and with the way that RDF is used (# URIs to refer to an
> arbitrary thing as described by the RDF - like maybe an XML element).
> A more realistic situation is where XML resolution gives an element
> and RDF "resolution" of the same URI gives something that is not an
> element - say, a data structure, a document, a type, a company, etc. I
> don't have an RDF/XML document in hand that exhibits this problem, but
> I note that it will arise almost any time rdf:ID is used (e.g. to do
> RDF reflection).

I hadn't considered that as a specific scenario - if RDF is used to make 
assertions about a elements in an XML document, then it may be reasonable that 
RDF should use XML-style fragment identifiers to identify such elements.  I 
think this is largely orthogonal to the design of RDF, and very much orthogonal 
the the RDF/XML syntax.

> (My factual question of whether generic XML processors must treat
> rdf:ID the same as xml:id hasn't been answered, by the way - so we're
> not sure there's a problem at all!)

I would say not.  Despite the apparent similarity of label, rdf:ID and xml:ID 
are completely different attributes.  (I've seen suggestions that rdf:ID be 
deprecated, as the same can be achieved using rdf:about.)

Received on Thursday, 7 October 2010 15:29:28 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:35 UTC