Re: fragment identifiers

Thinking about items 2-7 of Martin's email.

These comments, particularly item 3, seem to indicate that Martin is 
missing the point.  According to the approach described in Concepts, 
different MIME types are free to adopt their own fragid handling (I avoid 
saying 'semantics' here).  This isn't so much a decision as a recognition 
of the real world out there.

Which suggests that some editorial clarification may be needed.

BUT:
(a) this section has already been the subject of a fair amount of active 
debate during the first last call period, and
(b) the formal semantics leave no room for alternative treatments of 
fragment identifiers as they appear in an RDF graph, and this is just an 
explanatory section that attempts to explain how that view is not at odds 
with the conventional web-retrieval view.

THEREFORE:
I propose that we do not put the publication schedule and consensus already 
developed at risk by trying to address Martin's editorial points in the 
short period available to us.

Instead, I suggest that careful editorial work be undertaken for 
publication in an errata document, and subsequently in a revised 
publication of the Concepts document.

#g
--

At 02:40 10/11/03 -0500, Martin Duerst wrote:

>Dear RDF WG,
>
>This is a slightly late, personal, last call comment, about section 7
>(Fragment Identifiers) of the Concepts document.
>
>I have been reading this several times, and have been thinking about
>it for quite a while, but don't think I can tell you exactly how I think
>it should work. But I have a few comments for improvement.
>
>Please note that this is not about topics such as 'meaning of URIs'
>(although at some places, it may look like it gets near to it),
>it's more technical.

[...]

>2) The section should not use namespace notation (eg:someurl#frag), because
>    it is confusing (there is no place in actual RDF/XML, for example, where
>    a qname with a fragid can appear).
>
>3) The section should talk about other media types and other potential
>    rdf formats. For RDF to work, I think that all media types that encode
>    RDF data have to use the same conventions for fragment identifiers.
>    This may be done in a rather cursory fashion, but it shouldn't be
>    left out, to avoid the impression that each potential new type
>    would be totally free to use different #fragid semantics.
>
>4) As a special case of 3), and more in need of actual spec language, is
>    the case of RDF fragments embedded in other media types. A typical
>    example would be image/svg+xml. It has its own rules for fragment
>    identifiers, but it should say that the RDF fragments it may include
>    should be interpreted (including fragment ids) according to the rules
>    of RDF. Section 7 should say something to that effect, in a general
>    way, but clear and easy enough for other specs to pick it up. This
>    may also include some discussion about the case that a fagment id
>    is used both in the RDF part and in the e.g. SVG part of a document.
>    The advice for this case should be that this is a  bad idea unless
>    the RDF with that ID is metadata about the SVG with that id.
>
>5) In connection with 4), the sentence "So when eg:someurl#frag is used
>    in an RDF document, eg:someurl is taken to designate some RDF document
>    (even when no such document can be retrieved)." should be modified
>    to take care of cases such as embedded RDF in image/svg+xml.
>
>6) editorial:
>    "(itself, at least, also any other Web retrievable URIs that it
>      may use, possibly including schema URIs and references to other
>      RDF documents)"
>    should read:
>    "(itself, at least, but also any other Web retrievable URIs that it
>      may use, possibly including schema URIs and references to other
>      RDF documents)"
>
>7) In general, the issues here point to the fact that simply saying
>    "a fragment identifier is defined by the MIME type of the document
>    pointed to" (not exactly what the text says, but what it is often
>    thought to say) is rather inaccurate. It is well known that the
>    function of URIs depends both on the context where they are found
>    and on the thing they point to. Obvious examples are <img src='...'/>,
>    style sheet links, and so on. This also applies to fragment identifiers.
>    As an example, it is the <a href='...'/> context that decides that
>    the target document should (usually) replace the current document,
>    and the browser should *jump to* what it manages to identify (based
>    on the mime type) as the fragment identifier.
>    [this may be something that the TAG may also have to pick up]
>
>
>Regards,    Martin.

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Tuesday, 11 November 2003 08:05:00 UTC