Re: RDDL for describing fragment identifier facilities

["Simon St.Laurent" <simonstl@simonstl.com>]

[retrying after "permanent error; I've given up. Sorry it didn't work out."]

At 02:00 PM 5/8/01 -0400, John Cowan wrote:
 >Simon, as the author of XML Primer you know perfectly well that 35 is
 >not an ID, and anyway I didn't mean it to be.

Unless, of course, you're using AElfred.  But I thought the example was 
figurative.

 >I'm talking about a
 >mostly opaque resource type, video/flipbook, where the naive user
 >can either refer to the whole movie with no fragment id, or get a single
 >still by referencing it with a fragment id.

If video/flipbook is an opaque MIME type, the only way to know what the 
fragment identifier meant would be to read the registration - if any - for 
the MIME type.

 >A flipbook embedded in an arbitrary XML document can't use this convenient
 >form of fragment reference.  How could it?  Why should it?  XPointer,
 >though a fire hose as you say, will put out the fire.

It's a fire hose that SVG's creators have chosen not to use.  It's a fire 
hose that I don't think is especially appealing to many of the people 
building XML document formats and applications around those formats.

I'm not entirely sure why you'd want to prohibit svgview() for SVG embedded 
inside of XHTML.

 >Suppose there are five SVG graphics embedded in foo.xhtml.
 >Which one is addressed by foo.xhtml#svgview(...) ?

There's an ambiguity in the left-to-right reading of XPointers.  For 
certain schemes (notably xmlns), the reading of the scheme has an effect on 
the contents to the right of the XPointer.  For other schemes (notably 
xpointer), there's a short circuit - when a match is achieved, the rest is 
ignored.

I'd suggest the use of an context scheme that used XPath to establish 
context rather the short-circuit style functionality the xpointer scheme 
currently applies.  (You could just call it xpath, but someone might want a 
short-circuiting XPath...)

That way you could reach the graphic using a fragment identifier 
appropriate to your starting context, and then apply an identifier 
appropriate to that target.

 >The Right Thing in this case would probably be an svgview() *function*
 >within XPointer, so that you could say #xpointer(foo/bar/baz/svgview(...)
 >to drill down to the correct picture and then, in effect, switch models.
 >But this is still an XPointer, not a SVG fragment id.

No, there isn't a "Right Thing".  There are plenty of possibilities, not 
all of them mutually exclusive.  If you want to build the one true fragment 
identification processor, that might be the right thing, but there's still 
room for reasoned dissent on the matter.  XPointer offers schemes, but not 
much of a framework for applying them.  I'd like to see schemes taken seriously.