- From: Graham Klyne <GK@ninebynine.org>
- Date: Tue, 11 Nov 2003 11:24:39 +0000
- To: Martin Duerst <duerst@w3.org>
- Cc: me@aaronsw.com, "Eric Prud'hommeaux" <eric@w3.org>, w3c-rdfcore-wg@w3.org
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