Re: Generic processing of Fragment IDs in RFC 3023bis

I agree quite strongly with Roy.

I have some additional comments on the current text in section 5 of 
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html. 
It says:

 >>>>
A family of specifications define fragment identifiers for XML media 
types. A modular syntax and semantics of fragment identifiers for the 
XML media types is as defined by the [XPointerFramework] W3C 
Recommendation. It allows simple names, and more complex constructions 
based on named schemes. The syntax of a fragment identifier part of any 
URI or IRI with a retrieved media type governed by the specification 
MUST conform to the syntax specified in [XPointerFramework]. Conformant 
applications MUST interpret such fragment identifiers as designating 
that part of the retrieved representation specified by 
[XPointerFramework] and whatever other specifications define any 
XPointer schemes used. Conformant applications MUST support the 
'element' scheme as defined in [XPointerElement].
 >>>>

It is not clear what "governed by the specification" in the middle of 
this paragraph means. If it application/xml, text/xml,..., then I think 
it would be much clearer if it said "registered by this specification".
I also think that "Conformant applications MUST support the 'element' 
scheme" is too strong, there may be applications (e.g. syntax coloring 
editors) that take advantage of XML media types but don't do anything 
with fragment identifiers.


 >>>>
When an XML-based MIME media type follows the naming convention '+xml', 
the fragment identifier syntax for this media type MAY restrict the 
syntax to a specified subset of schemes, but MUST support barenames and 
'element' scheme pointers. It MAY further allow other registered schemes 
such as the xmlns scheme and other schemes.
 >>>>

Does "MUST support barenames" mean that the XML used in the media type 
has to have IDs? There may be some reasons why some XML formats have no 
IDs. As for 'element' scheme pointers, these are essentially supported 
by any kind of XML, just by the fact that it's XML.

I think what rather than "barenames MUST be supported" or "'element' 
scheme pointers MUST be supported", what we need from a +xml 
registration is a specification of what kinds of fragment identifiers 
applications that understand the specific media type are expected to 
understand. In many cases, this would ideally include barenames, and 
would also include 'element' scheme pointers. And it would also ideally 
follow the XPointer framework. But these are just SHOULDs, not MUSTs.

The spec then should also say that generic XML applications MAY use 
barenames and 'element' scheme pointers (and potentially other fragid 
syntaxes from the XPointer framework) even if they are not part of what 
the MIME type registration registers.

This would allow RDF to do what it does today, but also would allow e.g. 
'element' scheme pointers to be used with RDF in generic XML tools where 
appropriate.

Regards,   Martin.


P.S.: I have no idea why we are discussing 
http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html 
while this isn't submitted as an Internet Draft (the last version of 
that is http://tools.ietf.org/html/draft-murata-kohn-lilley-xml-03). I 
hope a new Internet Draft can be put out soon, and the relevant 
IETF-related list(s) can be cross-posted again.

On 2010/07/15 4:43, Roy T. Fielding wrote:
> On Jul 14, 2010, at 8:26 AM, Norman Walsh wrote:

>> 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
>
>

-- 
#-# Martin J. Dürst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

Received on Thursday, 15 July 2010 07:19:08 UTC