Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RDDL for describing fragment identifier facilities
 [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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
