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

Re: Generic processing of Fragment IDs in RFC 3023bis

From: Chris Lilley <chris@w3.org>
Date: Fri, 9 Jul 2010 17:35:28 +0200
Message-ID: <559211010.20100709173528@w3.org>
To: Noah Mendelsohn <nrm@arcanedomain.com>
CC: "MURATA Makoto (FAMILY Given)" <eb2m-mrt@asahi-net.or.jp>, "www-tag@w3.org" <www-tag@w3.org>, Norm Walsh <ndw@nwalsh.com>
(This discussion happened while i was on vacation; catching up on it now)

On Friday, July 2, 2010, 3:31:37 AM, Noah wrote:
NM> Jonathan Rees wrote:

>> there is
>> little assurance that future +xml registrations won't do the same
>> thing as rdf+xml and others, and specify fragid semantics that
>> conflict with generic processing.

NM> I don't think this is much of a concern.  If 3023bis is eventually 
NM> published as an RFC, 

That is the intention, once the issues raised against it are sorted

NM> then it can say explicitly: "the exception is for
NM> application/rdf+xml only;  generic processors should account for this 
NM> exception, and those registering new media types in the family 
NM> application/_____+xml MUST provide that all fragment ids are to be 
NM> interpreted per the generic rules in 3023(bis)"

This is ugly, but a specific exception for application/rdf+xml only is much prefersable, in my view, to the alternative asked for by the TAG to, as Norm put it, penalize all XML applications just because RDF has wierd handling of fragments.

NW> Just because RDF has an...interesting definition of 
NW> fragment identifiers is no reason to punish the rest of
NW> the XML world.


Actually, its not that RDF has additional, markup-specific fragment schemes that is the problem. Its that it does not follow the more generic fragment schemes *as well* which causes it to be so very different from every other +xml media type.

NM>    Thus, anyone 
NM> attempting to register a new type that did not support generic fragids
NM> would (should) fail in the attempt.

That would be good.

Indeed, Henry pointed out recently with respect to an ongoing +xml media type registration that it said nothing (in the registration) about fragments; and I suspect that many existing or in progress registrations are silent on the issue because the template in BCP 13, currently represented by RFC 4288, does not have anything about fragment identifiers.

The more specific fix for this, for application/xml and for +xml types, is to add such a section to the definitions of text/xml, application/xml (and freinds) and to the instructions for registering new +xml types.

A more general fix to the templates BCP 13 (adding a new section on Fragment identifiers) would also be a wise move.

 Chris Lilley                    mailto:chris@w3.org
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG
Received on Friday, 9 July 2010 15:38:57 UTC

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