- From: Henry S. Thompson <ht@inf.ed.ac.uk>
- Date: Thu, 29 Mar 2012 12:33:08 +0100
- To: www-tag@w3.org
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]
Received on Thursday, 29 March 2012 11:33:38 UTC