[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Future XSLT expansion. ( Re: Microsoft XSL and Conforman
Hi Didier, > Paul said: > My question is: do you see any way to utilize document()/part > hack when you have multiple document trees / sources, or document()/part > hack could be utilized only when processing multiple XML files ( something > identified by URL ) ? The *real* semantics of document()/part is: > > 1. Give me some data from the outher space. > 2. Filter that data with some criteria. > > The 'outher space' is considered to be XML file and only XML file + it > should > be *nodeset and only nodeset*. > > This is not scalable and very limiting. Not all the data in this world > are XSLT vendor-specific node-sets. > > Why should SQL engine bother itself with conversions of some table > into 'one-root-nodeset-alike' structure ( XSLT vendor specific nodeset > structure). > > Didier replies: > Error, the sql vendors will provide XML documents not node sets. So why are > you talking about node set returned by sql servers here? Not any data source could be represented by URI. Period. Think about the data from servlet session. Think about the current values of http-reqest. Learn from experience of some people who are trying to make this XSLT thing work in the real life. > Paul said: > It is XSLT paranoya to see everything in this world as > XSLT-vendor-specific-node-sets. > > Didier replies: > Take note here that you said that, nobody else said that and more > particularly not me. SQL vendors provide XML documents in text format not > node sets. However, this XML document is transformed into node set for > processing. Your design descisions are creating overhead on almost *any* component. "Let's continue bloating it because it is already bloated" is a consistent view of course, but I just can't take it seriosly. > Paul said: > XSLT is better to solve it's paranoya by itself. ( placing node-set > typecast into the core , but if making that step - what is the purpose of > having current document() semantics? No purpose, instead of > perlish 'send/recv and read/write' e t.c. ) > > I wish it is now clear. > > Didier replies: > Its your opinion. Yes, in my letter all oppinions is mine. And I also guess that in your letters all oppinions are yours. Great, it appears we have found some common ground here. > Paul said: > You are welcome. Because I have an impression that you don't > understand what that realy means I have explained it once again > in more detail. I'm sorry if that was disturbing. > > Didier replies: > What was disturbing Paul is that you said that I proposed this and that this > is not part of the specs. Sorry, you said that. And no, up to date I do not > see any convincing arguments, just opinions and opinions are undisputable. What is not an argument? The impact of node-set typecast on the entire processing model of XSLT is not an argument? I think you could easily ignore an elephant if it will not fit into your picture. > Paul said: > Yes. That's what I'm saying. > > 'documents other than the main source document'. This assumes the world is > full of XML documents and only XML documents (XML files) are to be > processed. > > That's just funny. That's what I was trying to explain. > > Didier replies: > So... What is the point here. The point is that the world is not full of XML documents and only XML documents. HTTP request does not come in the form of XML and unfortunately, it will take some time when it will. > > Paul said: > Of course it is valid. It is just ugly. I'm not saying 'send/recv' are > illegal in perl. > My point is that perl is a monster. And also my point is that with > document() > hack XSLT choosed perl-ish way. > > Didier replies: > OK its your opinion. Yes, it is. And to illustrate that point I found some words, explaining why the analogy between 'send/recv' and 'document()' is correct. So far I am now not finding any arguments in your letters instead of 'OK it is your oppinion'. If you'l not say "good point" about my comparsion of Tcl/Tk and perl I would not even try to explain to you that we have exactly the same situation with XSLT core. Unfortunately, I decided you can understand some things about the software other than "it is written on the page number NNN of document MMM". I was wrong, sorry about that and I see nothing to discuss here. Because: 1. Efficiency is not a problem to you. 2. Ease of writing extensions is not a problem to you. 3. Elegant, balanced API is not a problem to you. 4. What is currently written in some paper is not a big problem to me. ( 1 - 3 ) is a problem to me. Rgds.Paul. XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
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
|