Generic processing of fragment IDs in RFC 3023bis

Dear 3023bis editors,

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

Our reading of the current 3023bis draft is that a fragment id that is
not defined according to XPointer must be considered an error - in
particular, a fragid cannot obtain a non-error definition due to
fragid semantics specified in an application/ZZZ+xml media type
registration (for any value of ZZZ).  The problem is that this
XPointer interpretation would contradict the established interpretation
of fragment ids when the content is labeled as application/rdf+xml.

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

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

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

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

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

Best
Jonathan Rees
on behalf of the TAG

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

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

(tracker: ACTION-476)

Received on Monday, 22 November 2010 17:52:43 UTC