Re: Generic processing of fragment IDs in RFC 3023bis

Chris and Murata-san: thank you for your consideration of the TAG's concerns.

TAG members: it doesn't seem to me that there's need for further TAG 
discussion of this, so I won't be scheduling any unless prompted by one of 
you.  Thank you!

Noah

On 11/29/2010 9:02 AM, Chris Lilley wrote:
> 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)
>
>
>
>

Received on Monday, 29 November 2010 14:33:41 UTC