- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 5 Oct 2010 12:45:56 -0700
- To: Norman Walsh <ndw@nwalsh.com>
- Cc: www-tag@w3.org
On Oct 5, 2010, at 8:41 AM, Norman Walsh wrote: > Larry Masinter <masinter@adobe.com> 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. +1 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. ....Roy
Received on Tuesday, 5 October 2010 19:46:27 UTC