- From: Chris Lilley <chris@w3.org>
- Date: Fri, 9 Jul 2010 17:35:28 +0200
- 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. Quite. 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