[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RDDL for describing fragment identifier facilities
- From: "Simon St.Laurent" <firstname.lastname@example.org>
- To: John Cowan <email@example.com>
- Date: Tue, 08 May 2001 13:39:32 -0400
At 01:28 PM 5/8/01 -0400, John Cowan wrote: (in reverse order)
>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.
I think you may have noticed that I think the IETF theory of the matter is
excessively limited. I also think that "full generality XPointer" is a
fire hose for many applications where people would prefer a water
fountain. I'd be curious to know how many data-centric applications are
interested in using ranges between parts of nodes.
I think we've moved well past the simple two-level universe that MIME was
built for, and it's time to look around at the options that solve XML
problems. Namespaces were built explicitly for these kinds of cases, and
RDDL builds on that functionality.
>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
If #35 refers to an ID, and bare IDs are taken as minimal conformance for
XML fragment identifiers, I don't see the problem.
I'm not entirely sure why you'd want to prohibit svgview() for SVG embedded
inside of XHTML.
Simon St.Laurent - Associate Editor, O'Reilly & Associates
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books