Re: Generic processing of Fragment IDs in RFC 3023bis

Norm,

Thank you for this helpful clarification.  I am working on the agenda for 
the TAG F2F to be held 19-21 October, on the West Coast.  If we could line 
up schedules, would you have any interest in calling in for a discussion of 
this?  (The same offer is hereby extended to Roy and Martin, who are the 
other non-TAG members who have expressed significant concern with the TAG's 
suggested direction.)

If so, I'll try and make sure we have speakerphones available at our end. 
For the most part, our schedule is likely to be flexible, except for Wed. 
the 20th, when the afternoon is booked.

Thank you.

Noah

On 10/5/2010 11:41 AM, Norman Walsh wrote:
> Larry Masinter<masinter@adobe.com>  writes:
>> That said, I wanted to request more details for a specific use case
>> for the requirement in RFC 3023bis that XML content delivered with
>> content-type application/something+xml as the result of retrieving a
>> URI of the form uriA#fragmentB must be treated in a way that the
>> fragment identifier "fragmentB" follows generic XML fragment
>> identifier semantics.
>>
>> * I wanted to understand the requirement that the 'generic XML
>> fragment' actually be communicated via the fragment identifier of the
>> URI used to access the XML, rather than by some other alternative
>> communication channel. I understand the desire to support generic XML
>> processing, just not the communication channel for the fragment.
>
> While XInclude provides a separate channel for the fragment
> identifier, this is not generally the case. Most vocabularies that
> provide a mechanism for pointing to a resource do so with a single URI
> value, most often named "href".
>
> If I've only got one channel, it shouldn't be surprising that I want
> to use that channel for both the URI and the fragment.
>
>> * I wanted to understand why this requirement would only apply if the
>> URI (uriA) was a HTTP URI or some other URI that entailed
>> communication of a MIME type -- since ftp: or file: or many other
>> schemes don't have MIME types. Or is it expected that the fragments
>> would also work the same way even for other schemes?
>
> My understanding is that protocols that don't provide a MIME type
> leave the recipient with insufficient data to know the type
> authoritatively. Consequently, those recipients are under no
> obligation wrt the authoritative MIME type.
>
> Most systems that I've encountered that work with file: or ftp: URIs
> make assumptions about the MIME type based on the file extension. For
> .xml files served over those protocols, I do expect the system to
> assume they're application/xml and I do expect the fragment
> identifiers to be interpreted as such. But if they don't, I can't call
> them non-conformant.
>
>> * I wanted to explore the hypothetical situation of having two mime
>> types, e.g., application/frob and application/frob+xml, these two
>> having the identical definition, except for their use of fragment
>> identifiers. How would this work in practice in the use cases of
>> generic XML processing of fragment identifiers?
>
> It's a straightforward matrix, I think:
>
> 1. Content served as application/frob, recipient knows about
> application/frob
>
>    Fragment identifier interpreted as specified by application/frob
>
> 2. Content served as application/frob, recipient doesn't know about
> application/frob
>
>    Fragment identifier cannot be interpreted
>
> 3. Content serve as application/frob+xml, recipient knows about
> application/frob+xml
>
>    Fragment identifier interpreted as specified by application/frob+xml
>
> 4. Content served as application/frob+xml, recipient doesn't know about
> application/frob+xml
>
>    Fragment identifier interpreted as application/xml
>
> The screw case is the one where application/frob+xml specifies a
> fragment identifier syntax incompatible with application/xml. In that
> case, applications that fall into box 4 fail more-or-less badly.
>
> For my money, that's much less damaging than ruling 4 out of bounds
> for all applications for all +xml media types.
>
>> * I wanted to make sure we were not introducing incompatibilities in
>> the HTML "polyglot" case, where the same content could be delivered as
>> text/html and as application/xhtml+xml where the overall content had
>> the same result; would this requirement of generic XML processing of
>> fragment identifiers interfere with the use of fragment identifiers as
>> a means of passing parameters to scripting content of text/html.
>
> When are fragment identifier used for this purpose? I'm not saying it
> can't be done or hasn't been done, but surely the 99.9% case is that
> query parameters are used to pass parameters, not fragment identifiers.
>
>> I'm looking for specific software that you've written, used, or at
>> least have pointers to documentation for that need the 3023bis
>> requirement, and some explanation of how that software would work in
>> the situations outlined above.
>
> I've already given XProc as an example, but I think the situation is
> systemic. It has always been my assumption that 3023 would legitimize
> the fragment identifier syntax for the +xml media types.
>
>                                          Be seeing you,
>                                            norm
>

Received on Tuesday, 5 October 2010 15:50:38 UTC