Re: Generic processing of Fragment IDs in RFC 3023bis

Norm Walsh wrote:

> I find that unsatisfactory. It leaves generic XML processors out in
> the cold once again by expecting them to be aware of all of the media
> type registrations for all +xml formats.

That wasn't my intention.  On the contrary, I think we're agreeing that:

 > By creating a +xml format, you're explicitly signing on to a bunch of
 > constraints. The fragment identifier constraints for XML have been
 > informally understood but not standardized for years, that's a bug
 > that 3023bis should resolve.

Indeed.  All I was suggesting is that we insist that, at least in the 
future, +xml registrations explicitly acknowledge that.  This would

1) Help to ensure that the authors of those recommendations noticed 
their responsibility to support the generic syntax and

2) Make it somewhat harder for those who first read the +xml 
registration document to fail to notice the inheritance of generic 
fragid (and other) rules from 3023bis.

So, I think we agree, except perhaps on whether it's worth the trouble 
to require that +xml registrations >explicitly< acknowledge the generic 
rules, and I certainly don't feel strongly about that.  Sorry for any 
confusion.

Noah

Norman Walsh wrote:
> Noah Mendelsohn <nrm@arcanedomain.com> writes:
>> 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.
> 
> I find that unsatisfactory. It leaves generic XML processors out in
> the cold once again by expecting them to be aware of all of the media
> type registrations for all +xml formats.
> 
> By creating a +xml format, you're explicitly signing on to a bunch of
> constraints. The fragment identifier constraints for XML have been
> informally understood but not standardized for years, that's a bug
> that 3023bis should resolve.
> 
> If there are one or two existing +xml formats that have fragment
> identifier semantics that are inconsistent with application/xml, I'm
> content to have them enumerated.
> 
> Going forward, I think language designers should consider the tradeoff
> between a +xml media type and a specialty fragment identifier syntax
> and choose their media type accordingly.
> 
>                                         Be seeing you,
>                                           norm
>

Received on Tuesday, 13 July 2010 21:12:40 UTC