[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 15:52:19 -0800
builiding sets
----- Original Message ----- 
From: David Carlisle <davidc@xxxxxxxxx>

> > Exactly like document() hack works. It is turning text into node-set.
> No actually, it is returning an XML tree (node-set) as a result of
> passing a URI to a server. There never need have been a linearised form
> of the document returned, it could be the result of a database query.
> Or the parsing of some other syntax than XML that has a SAX parser.

I don't understand what you are saying here. I have document(URI)
in my stylesheet. The stylesheet is processed by XSLT engine.

What happens inside the XSLT engine from your point of view?

It takes the URI. It then sends it to the 'server' and 'server' returns 
the 'node-set' ? There is some standard client-server protocol 
which understands 'node-sets' ?

How can 'server' return 'node-set' ? 'Server' returns text. String.
XML file.

> > Why the same could not be done with just the text ( String ) ?

> Actually a string-parse() function that took a string and returned
> a node set might be useful in a few special cases, but I wouldn't
> like to see that all interfacing to external documents and extension
> functions went through such an interface, that would appear to
> lose  far too much functionality.

What in particular is lost after adding  the node-set typecast ?
> > 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. 
> even if you had a function converting strings to node sets, you'd still
> want the common API for node set expressions, otherwise what would you
> do with _arguments_ to the extension function that were node sets,
> surely you don't want to linearise them do you?

Why not? That's actualy the only way just to ship one compiled .jar file 
with some extension and that extension will then work with 
*any* XSLT implementation.

The only way to achive the same level of  scalability without this is to 
ask all XSLT vendors not only to use the same name for NodeSet 
class, but to use exactly the same *class*. 

Asking vendors to use the same name only allows not changing 
the code of the extension, but still means that each extension 
should be recompiled to be used with particular engine. Not that 
bad, of course ( but we are still not there, BTW ).

I have nothing against the unified API, but I still think that having 
typecasts in the core will be much easier to achive.

I have nothing against  passing node-set to the extension and 
getting node-sets back from the extension - that's more efficient.

Minor downside is that in the 'typecastish' world it is a bit easier 
to build some part of the tree on the level of extension, then 
append some other parts on the level  of stylesheet ( with concat(), 
for example), and then convert the resulting tree into node-set
and to do stuff like that, but that's realy a minor advantage.

Building any dataflow on top of some complex type ( node-set ) 
is for sure more efficient than builiding it on top of simple type 
( string ), but it is also for sure more complex thing to implement
and to support.

I would like to have both things. Bunch of servers and clients exchanging 
unified node-sets,  servlet session returning node-set, HTTP request 
provided by Apache in the form of node-set, the same NodeSet class 
shared  by every XSLT vendor  e t.c. - real interoperability - very cool. 
Unfortunately, I can not belive that  this bright new world will happen 

In the meantime converting the simple String into node-set will do 
the job in most cases.

> > I was bashed as a 
> not by me, I think

Yes, and I should apologize because you got a side effect of earlier 
bashing. I have been waiting  for  appropriate moment to apologize ;-)

> > after another, and still gives no way to capture the external 
> > text with the help of 'correct' document() ). 
> The two issues are quite distinct. You still want the API for node set
> (and other types) in extension functions even if you had a version of
> document that returned a string (or a text node). Actually you could
> import non XML text files now given a suitable server that served them
> as a text node, but as noted in the spec more convenient ways would be
> better

To me the issues are not distinct. There are some core types in XSLT 
( string and node-set in particular ). Having a conversion from one 
type to another is natural and easy way to solve wide range of problems in 
the uniform way. 

All I want is conversion between 2 core types to be in a core, but not 
in the status it has now. Some problems could be solved without 
such a conversion ( adding hidden typecasts to some places ), but I 
still think that's not a good way to do it.


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

Current Thread


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.
First Name
Last Name
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.