- From: John Cowan <jcowan@reutershealth.com>
- Date: Tue, 08 May 2001 13:28:31 -0400
- 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 UTC