Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XPath/XSLT 2.0 concerns
 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/ 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
