- From: Jonathan Rees <jar@creativecommons.org>
- Date: Mon, 20 Sep 2010 22:28:44 -0400
- To: Noah Mendelsohn <nrm@arcanedomain.com>
- Cc: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, "Roy T. Fielding" <fielding@gbiv.com>, Norman Walsh <ndw@nwalsh.com>, www-tag@w3.org, MURATA Makoto <eb2m-mrt@asahi-net.or.jp>, Chris Lilley <chris@w3.org>
I thought I understood the issue, but Alan Ruttenberg made me unsure... so let me see if I've got it. Please correct me where I'm wrong. The question is whether, for any URIref A#B, the 3023bis draft would mandate processing of A#B that would be at odds with what deployed or imagined RDF/XML processors do with A#B. For the question to arise, the resource A must have an RDF/XML "representation" with one of the ...+xml media types. Generic processing would only apply if the fragid B were defined in a way that would be seen by a generic XML processor, and this would be only if there were an xml:id="B" or equivalent. You wouldn't find xml:id in an RDF/XML document, but you might find rdf:ID. Does rdf:ID have to behave like xml:id with respect to generic processing? I think it does, but why? Something about the RDF/XML DTD? (I'm assuming that a fragid not defined according the media type registration of the retrieved representation MAY be defined in some other way, such as by a different retrieved representation (cf. FOAF which defines some fragids in an HTML representation and others in an RDF representation) or according to a spec not required by the registration. We've already discussed this in other contexts. The language in 3023bis does not recognize this possibility, which may be part of the problem.) So suppose we have <foaf:Person rdf:ID="B">... and that a generic XML processor treats rdf:ID like xml:id. 3023bis says that A#B would have to "designate" the foaf:Person *element*. I don't think there is any normative RDF-related document that says A#B has to "designate" anything other than the element (say, a foaf:Person), and in fact I would be distressed if there were. But in practice some applications act as if A#B does "identify" (variously, "name", "denote", etc.) a foaf:Person (i.e. that it does *not* identify an XML element), and it would be natural to insist that "designate" and "identify" have to be coherent. Recognition of generic XML processing by such RDF/XML processors, as would be mandated by 3023bis, might change the way they treat rdf:ID (for example, which RDF triples were asserted - people and elements clearly have very different properties). There cannot be any conflict when we have only <foaf:Person rdf:about="A#B">... or related definition-like uses of A#B since then the generic XML processor would know nothing about the URI A#B and would not make any assumptions about it, if it were encountered. But not all uses of rdf:ID can be replaced by rdf:about, so we can't just deprecate rdf:ID. We could probably divorce rdf:ID from xml:id pretty easily, if it isn't already, by revising RDF/XML, so that might be one way to go. Sound right? Looking forward to learning more about this, and seeing a realistic motivating example (Henry?). Jonathan [3023bis = http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html] On Mon, Aug 9, 2010 at 5:27 PM, Noah Mendelsohn <nrm@arcanedomain.com> wrote: > Martin, Roy, and Norm, > > Thank you for your comments on the TAG's suggestions regarding generic > processing of fragment identifiers for xml-related media types. I have been > asked by the TAG to inform you that we will take up consideration of the > concerns in the fall, after more of our members return from their summer > breaks. Thank you very much. > > Noah > > P.S. Tracker, this relates to TAG ACTION-453, the due date of which has been > changed to 7 Sept. 2010
Received on Tuesday, 21 September 2010 02:29:12 UTC