Re: Generic processing of Fragment IDs in RFC 3023bis

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

#g