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

Re: Future XSLT expansion.

Subject: Re: Future XSLT expansion.
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Mon, 20 Mar 2000 13:26:19 -0800
xslt typecast
> Even if teh API's for extensions were brought into line, it won't ever
> be really convenient to do this unless the extensions are all in the
> same namespace which means either an agreement between implementors
> (short term) or an official w3c extension namespace.

That is changing the stylesheet. That is easy ( of course, I would be 
happy if  vendors will agree on a common namespace, but if not - 
changing a few lines in the stylesheet header is not a big deal).

Changing the Java code of extension is much harder.
 
> > Returning Strings and allowing the typecast from Strings to node-sets
> > is better.

> ?? How in general would you get from a string to a node set?
> Parse it as XML? 

Exactly like document() hack works. It is turning text into node-set.
Why the same could not be done with just the text ( String ) ?

> In that case why not just return the node set
> directly, why force the internal tree to be linearised as a string and
> > reparsed? 

To have it portable means vendors should agree on the 
common NodeSet  class. That is possible, but that  is harder 
than placing to-node-set( String ) into the core. 

> > At that point it would be better to have to-node-set 
> > typecast  in the core.
> 
> You obviously have something in mind since youve posted so many messages
> in this thread all asking for the same thing, but I don't see it.

I have the same thing in mind right from the beginning. That's not my 
problem than instead of reading my letters I was bashed as a 
student, who has to read XPath specifation, address everything in this 
world with URIs and ignore  the ( de-facto existing ) node-set() typecast.  

I had to repeat my explanations.  ( and I still have to, because all the 
arguments for to-node-set() typecast are already in the thread in 
my first or second letter ).

> If the extension function is handling trees then it makes far more sense
> to pass back a tree (aka node set) than a string. 

Yes. So instead of introducing to-node-set typecast into the core you 
suggest:

a. Add one more 'hidden'  typecast ( variable -> node-set ).
b. Ask all vendors to use a common NodeSet class 
( 'political' typecast ).

That could be done ( but that's solving one particular problem 
after another, and still gives no way to capture the external 
text with the help of 'correct' document() ). 

I need to review some other places in the specs - 
there could be some more problems with missing typecast.
When system has some non-obvious datatypes and the typecast 
from/to core datatype is missing in the system - the system 
should have some more problems with that.

to-node-set typecast() still will be more scalable, 
because it at least gives some chance to use C 
extension ( returning String ) with Java XSTL engine.

> If it is not I don't see how in general you can convert to a node set.

Exactly like document() works ( because the real semantics 
of document() is to convert some text to node-set ).

Rgds.Paul.



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

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.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
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.