fragment identifiers

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.

Received on Monday, 10 November 2003 06:42:49 UTC