[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: RDDL for describing fragment identifier facilities
- From: "Simon St.Laurent" <email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 08 May 2001 15:00:51 -0400
[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
>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
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
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.