Re: Generic processing of Fragment IDs in RFC 3023bis

Martin, Roy, and Norm,

Thank you for your comments on the TAG's suggestions regarding generic 
processing of fragment identifiers for xml-related media types.  I have 
been asked by the TAG to inform you that we will take up consideration of 
the concerns in the fall, after more of our members return from their 
summer breaks.  Thank you very much.

Noah

P.S. Tracker, this relates to TAG ACTION-453, the due date of which has 
been changed to 7 Sept. 2010

Martin J. Dürst wrote:
> 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
>>
>>
>

Received on Monday, 9 August 2010 21:27:50 UTC