Re: Generic processing of fragment IDs in RFC 3023bis

On Monday, November 22, 2010, 6:52:04 PM, Jonathan wrote:

JR> Dear 3023bis editors,

JR> Following on to Norm Walsh's objection [1] to the TAG's previous
JR> communication on the subject of the treatment of "+xml" generic
JR> processing in the 3023bis draft [2], several TAG members took Norm's
JR> objection to heart, and investigated the issue more deeply.  We took
JR> up the subject again at our 19 October 2010 face-to-face meeting.

JR> Our reading of the current 3023bis draft is that a fragment id that is
JR> not defined according to XPointer must be considered an error - in
JR> particular, a fragid cannot obtain a non-error definition due to
JR> fragid semantics specified in an application/ZZZ+xml media type
JR> registration (for any value of ZZZ).

Yes.

JR>   The problem is that this
JR> XPointer interpretation would contradict the established interpretation
JR> of fragment ids when the content is labeled as application/rdf+xml.

Unfortunately, also yes.

JR> After a heated discussion, we enumerated at least five distinct ways
JR> to resolve this conflict, two of which met with general
JR> acceptance by those present.

Murata-san and I agree that of these, the second option is preferable.

The first one opens the door for random and undesirable handling, by allowing or seeming to encourage such registrations; while the second one merely recognises the only diverging use case that seems to matter and which has been a sticking point thus far.

JR> 1. Warn that fragid semantics may also be defined by an
JR> application/ZZZ+xml registration, in which case a generic processor
JR> might treat fragids in a document labeled application/ZZZ+xml in a
JR> manner inconsistent with that of a processor that is specific to the
JR> application/ZZZ+xml media type.  [The inconsistency may or may not
JR> lead to ill effects.]

JR> 2. Explicitly "grandfather" application/rdf+xml by exempting it from
JR> generic processing, as a special case.  That is, although
JR> application/rdf+xml contains the "+xml" morpheme, suggesting
JR> applicability of generic processing, generic processing is not to be
JR> considered valid in this one case.

JR> Then remove section 9.18 as application/rdf+xml would no longer be an example.

JR> We do not state a preference for one of these approaches over the
JR> other.

JR> Best
JR> Jonathan Rees
JR> on behalf of the TAG

JR> [1] Norm's objection (June 24):
JR>   http://lists.w3.org/Archives/Public/www-tag/2010Jun/0128.html

JR> [2]
JR> http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html

JR> (tracker: ACTION-476)




-- 
 Chris Lilley   Technical Director, Interaction Domain                 
 W3C Graphics Activity Lead, Fonts Activity Lead
 Co-Chair, W3C Hypertext CG
 Member, CSS, WebFonts, SVG Working Groups

Received on Monday, 29 November 2010 14:03:11 UTC