W3C home > Mailing lists > Public > www-xml-linking-comments@w3.org > April to June 2001

Re: RDDL for describing fragment identifier facilities

From: John Cowan <jcowan@reutershealth.com>
Date: Tue, 08 May 2001 13:28:31 -0400
Message-ID: <3AF82CBF.80104@reutershealth.com>
To: "Simon St.Laurent" <simonstl@simonstl.com>
CC: xml-dev@lists.xml.org, www-xml-linking-comments@w3.org
Simon St.Laurent wrote:


> It seems like RDDL could provide information regarding which fragment 
> identifier facilities are appropriate to content in a given 
> namespace.  This could make it possible, for instance, for svgView fragment 
> identifiers to operate properly on SVG embedded inside of other XML content 
> for which the svgView scheme would be inappropriate.

I think that would call for more cleverness than you could reasonably
expect.  Let's suppose that you have an XML format for flipbook movies
(the kind you get when you flip the corners of a book each page of which
has a line drawing on it), and you want a Very Simple fragment-id scheme,
something like "http://example.com/flipbooks/popeye.flip#35" meaning
frame 35.  We will suppose that there is a namespace for flipbook elements.

Now suppose that you have a compound document with multiple embedded
flipbooks.  What sort of fragment ids would you expect to work on that
compound document?  Surely not just #35 for the 35th frame (of which
flipbook)?

The IETF theory of the matter is that the meaning of a fragment id is
defined solely by the media type of the resource.  If a resource has
the type video/flipbook, then #35 means the 35th frame, as given by
the definition of video/flipbook.  If a resource has type text/xml
or application/xml, then full generality XPointer is your only man.

-- 
There is / one art             || John Cowan <jcowan@reutershealth.com>
no more / no less              || http://www.reutershealth.com
to do / all things             || http://www.ccil.org/~cowan
with art- / lessness           \\ -- Piet Hein
Received on Tuesday, 8 May 2001 13:30:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:39:42 GMT