Re: fragment identifiers

The deleted I-D appears to be a mistake.  I've just sent a message to the 
I-D editor, but due to the IETF meeting in progress it may not be seen for 
a while.

Anyway, my understanding and recollection is that the MIME type 
registration does refer to the Concepts document.

I'll digest and contemplate the other points separately.

#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.
>
>
>1) Given the central role of the Concepts document for RDF, and the
>    central role of URIrefs, including fragment identifiers, for RDF, I think
>    it's not a good idea to have draft-swartz-rdfcore-rdfxml-mediatype-xx.txt
>    define how fragment identifiers work, and the Concepts draft refer
>    to it. It should be the other way round.
>    [W3C is working together with the IETF on being able to include
>     MIME type registrations directly in W3C Recs, and depending on
>     timing, that may happen for RDF, but that still leaves the
>     question of where in the document the fragment identifiers
>     would be defined.
>     In addition, it seems the draft has expired. At
> 
>http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediaty 
>http://www.ietf.org/internet-drafts/draft-swartz-rdfcore-rdfxml-mediatype-04. 
>txt,
>     I get:
>        >>>>
>        This Internet-Draft has been deleted. Unrevised documents placed 
> in the
>        Internet-Drafts directories have a maximum life of six months. After
>        that time, they are deleted. This Internet-Draft was not published as
>        an RFC.
>
>        Internet-Drafts are not an archival document series, and expired
>        drafts, such as this one, are not available; please do not ask for
>        copies... they are not available. The Secretariat does not have
>        information as to future plans of the authors or working groups 
> WRT the
>        deleted Internet-Draft.
>
>        For more information or a copy of the document, contact the author 
> directly.
>
>        Draft Author(s):
>
>        A. Swartz: me@aaronsw.com
>        >>>>
>
>        That makes it difficult to comment on some aspects, but I'll try
>        anyway.
>    ]
>
>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:04:56 UTC