Fragment identifiers, RFC3023bis: Preparing for the F2F (ACTION-675)

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