[
Lists Home |
Date Index |
Thread Index
]
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:
foo/#psvi:type-definition
then you'd get an element node that represented the W3C XML Schema
type definition property of the element. Or if you did:
foo/#xlink:link-definition
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...
Cheers,
Jeni
---
Jeni Tennison
http://www.jenitennison.com/
|
