Re: RDDL for describing fragment identifier facilities

[Jonathan Borden <jborden@mediaone.net>]

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