Re: Generic processing of Fragment IDs in RFC 3023bis

Chris Lilley writes:

> Indeed, Henry pointed out recently with respect to an ongoing +xml 
 > media type registration that it said nothing (in the
 > registration) about fragments

That seems to me nearly as a much a potential bug as the rdf+xml 
registration, in that it doesn't explicitly commit to the generic 
interpretation.  Thus one could imagine application/notgood+xml being a 
vocabulary in which it is not intended that <x id="foo"> be matched by 
xpointers in the obvious manner, and that would be bad too.  I doubt 
anyone would do this maliciously, but it is quite possible that someone 
doing a registration would fail to notice the fact that they were, in 
fact commiting (via 3023bis) to a whole family of URI references 
involving XPointer.

So, I'm tempted to suggest that 3032bis should require that ____+xml 
registrations explicitly commit to the generic syntax.  I suppose one 
would have to do a hand wave about existing registrations, but we might 
do our best at least to catch re-registrations and new registrations.

Noah

Chris Lilley wrote:
> (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.
> 
>

Received on Saturday, 10 July 2010 12:57:47 UTC