W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2016

[Bug 29608] Fragment identifiers: fn:doc vs. fn:unparsed-text

From: <bugzilla@jessica.w3.org>
Date: Sun, 08 May 2016 19:46:09 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29608-523-KH4ZD3JQRl@http.www.w3.org/Bugs/Public/>

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
                 CC|                            |abel.braaksma@xs4all.nl

--- Comment #3 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
The fragment identifier is defined with the MIME type of a document and may
depend on the serving application.

W3C says this:
"The significance of the fragment identifier is a function of the MIME type of
the object.[...]The fragment ID spec for a new MIME type should  be part of the
MIME type registration process."

And RFC-3986 says: "The fragment's format and resolution is [..] dependent on
the media type [RFC2046] of a potentially retrieved representation. [..]
Fragment identifier semantics are independent of the URI scheme and thus cannot
be redefined by scheme specifications."

Here are some examples of such MIME types:

- RFC-5147 defines fragment ids for text/plain through "char" and "line"
- RFC-7111 defines it for text/csv for "col" and "row"
- RFC-3778 defines it for application/pdf (page no, section, ref etc)
- W3C has a Recommendation for Media Fragments:
- Some languages support package download (like Python) and add the MD5 hash as
a fragment identifier to the URI, which then either retrieves the whole
document or an error (if the MD5 does not match). This could well be used with
any resource.
- This same MD5 check, or a length-check is also part of RFC-5147.

So I think Christian has a good point and perhaps we should say something about
it, and at the very least allow it with unparsed-text etc as well (in fact, I
think we should allow it with any external resource).

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Sunday, 8 May 2016 19:46:12 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 8 May 2016 19:46:12 UTC