Re: Generic processing of Fragment IDs in RFC 3023bis

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