[
Lists Home |
Date Index |
Thread Index
]
> Jeni Tennison wrote:
>
> > 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.
>
> > 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?
I would strongly oppose a move for abbreviation of extension axes. For one
thing, this would throw chaos into the idea of having a basic grammar for
XPath. I also think it would be terribly confusing for the users. What if
two groups choose "#" for their abbreviated axis name? Users could see "#" as
meaning type axis in some examples/implementations and "#" meaning hyperlink
axis in another. Would we have to end up with a global registry of abbeviated
axis names? And wouldn't there then be a hasty lang-grab for cute and
memorable abbreviations?
In general, I don't think it's necessary. Extension axes are likely to see
much less use than child::, attribute::, etc., and I see no reason why they
shouldn't always be spelled out.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/
Python&XML column: Tour of Python/XML - http://www.xml.com/pub/a/2002/09/18/py.
html
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w
ebservices/library/ws-pyth10.html
|
