Re: Generic processing of Fragment IDs in RFC 3023bis

Hello Larry,

Indeed there may be a tension between generic fragments for all XML 
content and generic fragments across content negotiation. However, I 
think that tension will be resolved (by using LCD) for individual cases, 
without needing a general balance to tip in any direction. As an 
example, for identifiers that work across XML data, a graphic 
representation of that data as SVG, and an HTML representation, you'd be 
stuck with using 'barenames' anyway, and for other combinations (e.g. 
those including text/plain), you won't be able to find a fragment id 
that works for all formats.

Regards,    Martin.

On 2010/09/01 4:38, Larry Masinter wrote:
> re ACTION-453...
>
> I've skimmed the discussion on this.  The thing I'm wondering is what the
> relative tradeoff of benefit is between generic processing of fragment
> identifiers for XML documents, vs. generic processing of fragment identifiers
> for content-negotiated or polyglot documents.
>
> On the one hand, I hear people claiming that they have use cases where
> being able to consistently process URL fragment identifiers for all XML
> documents is a "good thing". I don't understand the use cases for this,
> though. I understand the benefits of generic processing of fragments, but
> not why those fragment identifiers might always be trasmitted in URLs.
>
> On the other hand, there is some benefit in being able to consistently
> have fragment identifiers which work "the same" even between XML and
> non-XML representations, so that   book-url#chapter=10  might work for
> both an XML and a non-XML representation of the book.
>
> This might be of benefit in the polyglot HTML / XHTML use case, for example.
>
> So I see a trade-off, and to me the balance tips toward not insisting that
> fragment identifiers for XML-based media types always use generic XML
> fragment processing.
>
> Larry
> --
> http://larry.masinter.net
>
>
> -----Original Message-----
> From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of Noah Mendelsohn
> Sent: Monday, August 09, 2010 2:27 PM
> To: "Martin J. Dürst"; Roy T. Fielding; Norman Walsh
> Cc: www-tag@w3.org; MURATA Makoto; Chris Lilley
> Subject: 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
>>>
>>>
>>
>

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

Received on Wednesday, 1 September 2010 01:27:11 UTC