- From: <bugzilla@jessica.w3.org>
- Date: Sun, 08 May 2016 19:46:09 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29608
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:
(https://www.w3.org/DesignIssues/Fragment.html)
"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:
https://www.w3.org/TR/media-frags/
- 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