Re: Generic processing of Fragment IDs in RFC 3023bis

On Oct 5, 2010, at 8:41 AM, Norman Walsh wrote:
> Larry Masinter <> writes:
>> * I wanted to explore the hypothetical situation of having two mime
>> types, e.g., application/frob and application/frob+xml, these two
>> having the identical definition, except for their use of fragment
>> identifiers. How would this work in practice in the use cases of
>> generic XML processing of fragment identifiers?
> It's a straightforward matrix, I think:
> 1. Content served as application/frob, recipient knows about
> application/frob
>  Fragment identifier interpreted as specified by application/frob
> 2. Content served as application/frob, recipient doesn't know about
> application/frob
>  Fragment identifier cannot be interpreted
> 3. Content serve as application/frob+xml, recipient knows about
> application/frob+xml
>  Fragment identifier interpreted as specified by application/frob+xml
> 4. Content served as application/frob+xml, recipient doesn't know about
> application/frob+xml
>  Fragment identifier interpreted as application/xml
> The screw case is the one where application/frob+xml specifies a
> fragment identifier syntax incompatible with application/xml. In that
> case, applications that fall into box 4 fail more-or-less badly.
> For my money, that's much less damaging than ruling 4 out of bounds
> for all applications for all +xml media types.


It is important to understand that the "confusion" that might be caused
to an RDF graph due to the (very unlikely but) potential dual use of
fragment syntax is entirely disambiguated by the fact that the graph
processor does know RDF and therefore will choose (1) above.  All other
cases will only be encountered by applications that do not process RDF
as a graph (e.g., XML editors) and do not get confused in that way.

The issue left is that some non-RDF user may mint a URI to point to their
favorite portion of XML within an RDF page, and then send that URI to
others (a common scenario in code reviews).  For that reason, it would be
wise for RDF/XML to preallocate the subset of its fragment space that looks
like the XPointer syntax to have the semantics of XPointer and not be
available for arbitrary assignment within the graph.  Such a decision can
be made by the RDF/XML maintainers.

The above is independent of whatever 3023bis says -- it just works that
way now and there is nothing anyone can do about it short of stop using
XML.  Changing the media type would not matter.

My suggestion for 3023bis is that it include what Norm writes above and
make it clear that the XPointer syntax will be used on XML even if the
specific media type does not have its own definition for that syntax.
Media type +xml definers should therefore be encouraged to include the
XPointer syntax within its own definition of fragments in a way that
allows the XPointer-specific syntax to have consistent semantics with
its use to identify portions of a document.  Where ambiguity might
be present, bare name fragments always refer to the semantics defined
by the specific media type.


Received on Tuesday, 5 October 2010 19:46:27 UTC