Fragids status report [partial]: ACTION-567

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I've reviewed the situation, and offer the following summary of where
we stand.  Much of this starts from Jeni's earlier [0] introduction.

1) 'Official story': in general

The two relevant high-level documents, namely RFC 3986 [1] and AWWW
[2] place only minimal constraints on the syntax and semantics of
fragids.  RFC 3986 in particular emphasizes the flexibility granted to
user agents with respect to fragid processing.  The one moderately
strong constraint expressed by both RFC 3986 and AWWW is that in the
case of content negotiation, whatever subset of the possibly returned
media types specify a fragid semantics should identify the same
resource for all (types of) fragids.

2a) 'Official story': in particular, _status quo_

Three obviously relevant existing media type registrations, namely
HTML [3], XHTML [4] and RDF/XML [5], all appear to _assume_ that
fragids are syntactically names, without actually mandating this, or
specifying what, if anything, is to be done in the case of non-name
strings.

SVG [6] requires that a fragid for application/svg+xml docs is
_either_ an 'XML_Name' (without further explanation) with or an SVG View,
of the form svgView(...).

2b) 'Official story': in particular, in progress

The draft application/xml and application/...+xml media type
registration (RFC 3023bis [7]) covers both names (by reference to the
XPointer Framework spec. [8]) and more complicated fragids which are
in the form of registered XPointer schemes [9].  It _requires_ that in
_all_ cases the semantics are such as to "[designate] that part of
_the retrieved representation_ specified by [XPointerFramework] and
whatever other specifications define any XPointer schemes used."
[emphasis added]

The draft N3 media type registration [10] mandates name syntax by
reference to 'qname' (again, without any explicit reference or
definition).  It explicitly makes the semantics completely
unconstrained in the general case:

 "The fragment identifier part of a URI where the rest of the URI is
  that of an information resource which has a representation in N3 is
  used to identify any thing whatever, abstract or concrete."

The draft text/html media type registration [11] doesn't constrain the
syntax beyond what RFC 3986 does, but specifies a semantics of DOM
nodes identified by ID or NAME attribute matching.

[out of time, so this stands as a partial introduction for the time
 being -- to be continued]

ht

[0] http://lists.w3.org/Archives/Public/www-tag/2011May/0089.html
[1] http://tools.ietf.org/html/rfc3986#page-24
[2] http://www.w3.org/TR/2004/REC-webarch-20041215/#fragid
[3] http://www.rfc-editor.org/rfc/rfc2854.txt
[4] http://www.rfc-editor.org/rfc/rfc3236.txt
[5] http://www.ietf.org/rfc/rfc3870.txt
[6] http://dev.w3.org/SVG/profiles/1.1F2/publish/linking.html#SVGFragmentIdentifiers
[7] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#frag
[8] http://www.w3.org/TR/xptr-framework/
[9] http://www.w3.org/2005/04/xpointer-schemes/
[10] http://www.w3.org/TeamSubmission/2011/SUBM-n3-20110328/#frag
[11] http://www.w3.org/TR/2011/WD-html5-20110525/iana.html#text-html
- -- 
       Henry S. Thompson, School of Informatics, University of Edinburgh
      10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
                Fax: (44) 131 651-1426, e-mail: ht@inf.ed.ac.uk
                       URL: http://www.ltg.ed.ac.uk/~ht/
 [mail from me _always_ has a .sig like this -- mail without it is forged spam]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)

iD8DBQFOQ/RfkjnJixAXWBoRApg2AJ9nTceIu6zW0dSBCtFXgc39ncA95ACePi+X
Y6nDTIfNLm1EYY+ZZVv11vs=
=0LcM
-----END PGP SIGNATURE-----

Received on Thursday, 11 August 2011 15:25:45 UTC