OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RDDL for describing fragment identifier facilities

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