W3C home > Mailing lists > Public > www-tag@w3.org > November 2010

Re: Generic processing of fragment IDs in RFC 3023bis

From: Noah Mendelsohn <nrm@arcanedomain.com>
Date: Mon, 29 Nov 2010 09:33:11 -0500
Message-ID: <4CF3B9A7.1020201@arcanedomain.com>
To: Chris Lilley <chris@w3.org>
CC: Jonathan Rees <jar@creativecommons.org>, Murata Makoto <eb2m-mrt@asahi-net.or.jp>, www-tag@w3.org, Norman Walsh <ndw@nwalsh.com>
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!


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:36 UTC