Re: Generic processing of Fragment IDs in RFC 3023bis

On Jul 14, 2010, at 8:26 AM, Norman Walsh wrote:

> Noah Mendelsohn <nrm@arcanedomain.com> writes:
>> 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.
> 
> Ok. Good. To be concrete, here's what I think I'd like 3023 to say:
> 
> 1. +xml media types SHOULD use application/xml semantics for fragment
>   identifiers.
> 
> 2. Media type registrations for +xml media types should explicitly
>   acknowledge that they use 3023 fragment identifier semantics
> 
> 3. Unless a media type registration for a +xml media type explicitly
>   says otherwise, generic XML processors are licensed to attempt to
>   resolve fragment identifiers using the application/xml
>   semantics.

I agree with Norm, though I think it should be even less constrained
than the above.

Fragment identifiers don't appear out of thin air -- they are used for a
purpose.  For any given media type (XML or not), the proper interpretation
of a fragment identifier is first determined by the representation in hand
according to the media type's rules.  It is only when that process fails
to find any definition of the identifier that the generic processing
behavior might be applied, depending on the kind of request being made.
Hence, 3023bis-style generic processing, Xpointer, or others might apply
to RDF during a retrieval action for a fragment id if the media type
is RDF+xml and the RDF representation fails to define the corresponding
fragment.

And, quite frankly, RDF does not have a vote.  This kind of fallback
behavior is the most natural way to handle XML within editors that
probably don't know anything about RDF and within XML processing
languages that simply don't need to care.  It has no impact on the
RDF semantics for the identifiers that are actually defined by the
graph, which are the only ones that apply during RDF processing,
so I see nothing to gripe about.

In any case, if you don't want to get dirty then don't live in
a pig's sty.  There are plenty of non-XML ways to represent RDF.

....Roy

Received on Wednesday, 14 July 2010 19:43:55 UTC