[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RDDL for describing fragment identifier facilities
Simon St.Laurent wrote: Firstly, I think it is time to define a basic non-media type dependent syntax for fragment identifiers. XPointer is actually close to the mark. I would limit this to two specific parts: 1) a raw name ... this takes care of how fragment identifiers are used today. 2) a scheme based syntax That is the child seq syntax in XPointer should be reworked as childseq(/1/2/3) > > 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...) There is no reason this need be the case. #xpointer(...) can be 'viewed' as returning a current context that is passed along to the next scheme e.g. #xmlns() xpointer(...) foo(...) > > 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. right. > > >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. What we really really need is to define an overall fragment id syntax which is not dependent on each media type, because the media type is only known in the context of a particular http transaction (for example). XPointer types schemes are a way around this, each scheme might be 'registered' independently and a user agent might ignore certain schemes in the context of a particular media type. The idea that a fragment id syntax is dependent on a particular media type is fairly broken and I think that schemes are a reasonable way to begin to fix this. -Jonathan
|
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
|