[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RDDL for describing fragment identifier facilities

  • From: Jonathan Borden <jborden@m...>
  • To: "Simon St.Laurent" <simonstl@s...>, xml-dev@l...
  • Date: Tue, 08 May 2001 15:54:33 -0400

circuit facilities identifier
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.