Re: Generic processing of Fragment IDs in RFC 3023bis

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

-- 
Norman Walsh
Lead Engineer
MarkLogic Corporation
www.marklogic.com