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

Re: XPath/XSLT 2.0 concerns

core xpath
Hi David,

>> I do worry a bit about moving such stylesheets between schema
>> languages if what you find at the end of the schema:: axis could be
>> different from schema language to schema language.
> I don't worry that much. I don't think it will happen very often
> that you change schema language for a particular application. And
> when it happens it is not by accident so you will know to check for
> the use of the schema axis. I'ts a bit like changing datatype
> library in your RELAX NG schema.

I remember discussing the same kind of thing surrounding extension
functions for XPath and why having a standard namespace for those
extension functions is a good thing. I shouldn't phrase it so much in
terms of moving a stylesheet from one environment to another -- what
happens more often, and is more important for me as a programmer, is
that *I* move from one environment to another, and *I* get confused
remembering how a particular function (or axis) works in a particular
environment :)

But I think I'm probably misinterpreting what you meant with the
schema:: axis -- I was thinking that it was getting all sorts of
information from the schema, whereas I think you were mainly looking
at accessing type information?

>> What I've been dreaming about, for my fantasy XPath, is something
>> where axes themselves are fairly modular from word go. (Basically
>> they're just a shorthand for calling a function that accepts a node
>> and returns a sequence of nodes, but to make it fit with node tests
>> and predicates you need to also specify its principal node type and
>> whether it's a forward or reverse axis.) Core XPath would define
>> the abbreviated axes: child, parent, descendant-or-self. The
>> XPath-for-XSLT module would add the other ones used by XSLT. And
>> then other modules could specify whatever axes they wanted, in a
>> namespace.
> Sounds like an interesting idea. What about abbreviation
> possiblities then? I guess this approach excludes abbreviations from
> the extension axes or should it be a part of the axis definition?

All the abbreviated axes would be defined in the Core XPath (sorry, I
forgot to include attribute:: to my list there). You'd have to type
the other axes long-hand. I think that's necessary in order to create
a specification of XPath syntax that could be parsed by something that
doesn't necessarily know which modules have been included?

Of course one possibility would be that this Core XPath had a
definition of a # or ~ abbreviation for a "property" axis, providing
element nodes that represented whatever extra Infoset properties the
upstream processor wanted to add to the particular node. So for
example, if you did:


then you'd get an element node that represented the W3C XML Schema
type definition property of the element. Or if you did:


you'd get an element node that represented an XLink specification for
what the node was supposed to do.

That could be quite flexible; it would mean that the extra "modules"
would essentially only be providing shortcuts through this "property"
axis and to the information beyond. Hmm...



Jeni Tennison


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.
First Name
Last Name
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.