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

Re: XPath/XSLT 2.0 concerns

• To: "David Rosenborg" <darolst@p...>
• Subject: Re: XPath/XSLT 2.0 concerns
• From: Uche Ogbuji <uche.ogbuji@f...>
• Date: Mon, 07 Oct 2002 00:50:48 -0600
• Cc: "Jeni Tennison" <jeni@j...>, xml-dev@l...
• In-reply-to: Message from "David Rosenborg" <darolst@p...> of "Fri, 04 Oct 2002 14:52:51 +0200." <003801c26ba4$f32a4f00$a25fd7d9@TYPHOON>
• Sender: uche.ogbuji@f...

> 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

• Follow-Ups:
  • Re: XPath/XSLT 2.0 concerns
    • From: "David Rosenborg" <darolst@p...>

• References:
  • Re: XPath/XSLT 2.0 concerns
    • From: "David Rosenborg" <darolst@p...>

• Prev by Date: Re: XPath/XSLT 2.0 concerns
• Next by Date: Re: SGML on the Web
• Previous by thread: Re: XPath/XSLT 2.0 concerns
• Next by thread: Re: XPath/XSLT 2.0 concerns
• Index(es):
  • Date
  • Thread