The background to this discussion is well-linked from the agenda [1]
and the agenda from _last_ June's f2f [2].
Our aims a year ago were
1) make decision on direction we take on RDFa Core
2) agree text for MIME and the Web draft on fragids
3) make decision (again) on direction we take on 3023bis (application/xml)
4) identify other actions to resolve fragid issues
Of these, (1) is half-done. RDFa Core is in CR, with the following
text in place, as agreed between the TAG and the HTML WG:
"The precise meaning of IRIs which include fragment identifiers
when they appear in RDF graphs is given in Section 7 of
[RDF-CONCEPTS]. To ensure that such fragment identifiers can be
interpreted correctly, media type registrations for markup
languages that incorporate RDFa should directly or indirectly
reference this specification." [3]
This addresses the so-called "follow-your-nose" concern, but leaves
open the "#-URI semantics" concern.
(2) is in flux in one sense, in that exactly what document(s) will be
taken forward in this area is subject to discussion.
But (3) and the general question of frag-id semantics and where they
are specified are still very much open.
So, to try to give us some achievable targets, here's a slightly more
detailed set of discussion topics/aims for the F2F:
1) Should the advice in AWWW regarding the interaction of conneg and
fragids [4] be understood as referring to consistency at the level
of specifications or at the level of individual
(pairs/triples/... of) URIs? Which _should_ it be about? Do we
still think it's good advice?
See a thread of discussion between JAR and myself, with my
position set out at [5].
I'm putting this first not because I think the conneg vs. fragid
issue is of profound practical importance, but because it
foregrounds most of the key distinctions we need to be clear
about.
2) What changes, if any, do we now want to see made in what
RFC3023bis says about fragment identifiers [6]? Are we still
happy with our request to the editors [7] and the editors' stated
preference for our option (2):
"2. Explicitly "grandfather" application/rdf+xml by exempting it
from generic processing, as a special case. That is, although
application/rdf+xml contains the "+xml" morpheme, suggesting
applicability of generic processing, generic processing is not
to be considered valid in this one case."
Note that there is an interaction here with RDFa: A URI such as
http://examples.tobyinkster.co.uk/hcard#jack is not just in
principle, but in practice contradictory, and the above proposed
change will _not_ fix this. To see the problem, point e.g. Ivan
Herman's RDFa distiller [8] at
"http://examples.tobyinkster.co.uk/hcard" and then point your
browser at http://examples.tobyinkster.co.uk/hcard#jack
As similar example is at http://www.ivan-herman.net/foaf
respectively http://www.ivan-herman.net/foaf#SWActivityBlogAccount
I _think_ in this case it is the page authors who are at fault,
but explaining to him _why_ this is the case may prove
difficult. . .
3) What next for Jeni's draft finding [9]?
ht
[1] http://www.w3.org/2001/tag/2012/04/02-agenda#XMLfrag
[2] http://www.w3.org/2001/tag/2011/06/06-agenda#mimefrag
[3] http://www.w3.org/TR/rdfa-core/#s_Syntax_overview
[4] http://www.w3.org/TR/webarch/#frag-coneg
[5] http://lists.w3.org/Archives/Public/www-tag/2012Feb/0047.html
[6] http://www.w3.org/2006/02/son-of-3023/draft-murata-kohn-lilley-xml-04.html#frag
[7] http://lists.w3.org/Archives/Public/www-tag/2010Nov/0078.html
[8] http://www.w3.org/2007/08/pyRdfa/
[9] http://www.w3.org/2001/tag/doc/mimeTypesAndFragids-2011-08-12
--
Henry S. Thompson, School of Informatics, University of Edinburgh
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 650-4587, 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]