Subject: Re: Future XSLT expansion. ( Re: Microsoft XSL and Conformance ) From: Paul Tchistopolskii <paul@xxxxxxx> Date: Thu, 16 Mar 2000 23:15:05 -0800 |
Hi Didier , > > Jonathan Borden said: > > Again, the most important feature for me, not yet implemented is > document() > > support. Hint Hint... > > > > Didier replies: > > I cannot agree more on that. the Document() function is the angular stone > of > > web services usage based on URL request. Just imagine having the > possibility > > to make a SQL call with a URL and get back an XML document fragment. > > Furthermore, to be able to get within that fragment the exact > > element/elements through Xpath. As a concrete example: > > > > document('http://www.mysqlserver.com/sql=select * from mytable')/row/name > > Paul said: > Just in case - why not > > document('http://www.mysqlserver.com/sql=select name from mytable') > > Didier replies: > Yes you are right, you can do that, So I probably picked the wrong example. > But I can assure you that in some cases you cannot access the element > directly from the URL. Just consider an other kind of URL request for a web > service: > > document('http://www.moreover.com....and some other parameters-sorry I > cannot say morte without Moreover permission')/url > > So, in that case the web service returns a full hierarchy of elements. The > XPath expression is used in that case to get the right elements. Actualy, this example has exactly the same disadvantage that your first example has. Let us just spend a few seconds thinking what realy happens. We have a client and server here. In your scenario: Client ( executing XSLT stylesheet ) makes a request to the server for some data. Client receives some heap of data from server. Client then is using ony *part* of that heap ( filtering the heap with some criteria ). But the entire heap has been transfered to the client. Overhead. In my scenario: Client makes a request to the server and *server* filters the heap. That means client gets only the data it needs. The same collision takes place in PXSLServlet. PXSLServlet is creating XML from SQL. Then XSLT Stylesheet preforms rendering of that XML. When I need some data sorted / filtered I'm using ORDER BY part of SQL query, even I could sort on the level of XSLT. Yes I could. But if the 'source' could make some preprocessing ( ordering, filtering ) - why should XSLT part bother with sorting and filtering ? The last by not the least. The functionality you are asking for: document('http://www.moreover.com/parameters-here')/url Equals to: $var = document('http://www.moreover.com/parameters-here'); select $var/url This could be already done with XSLT without polluting the semantics of document() function. > Paul said: > > Yes indeed, the document function is where the magic potion is hidden > > I don't think it is a good idea to turn XSLT into yet another monster > with things like that. > > I think XSLT's extension elements could ( should ) do things like that. > > ( I actualy think that it could be better to remove some stuff from XSLT to > achive better balancing between core XSLT and extensions, but that's another > story.). > > Isn't it strange that fundamental node:set 'typecast' is not in a core, > but some other things are in there ? > > Didier replies: > So your opinion is that the document function part of the XSLT 1.0 > recommendation is a monster? I think : document() is simply a logical hack ( like most other solutions from XML world, the hack is nice and handy, of course ). What it *realy* is: a. "get data" b. "convert data to nodeset". (a) could be text file, identified by URL, but it could also be any other source. Actualy, XSLT transformation couild be already invoked over DOM. In this case what if I have *2* DOMs ? Do I understand right that having multiple input files is 'legal', but having multiple DOM's is 'marginal' ? (b) is not in XSLT standart. *that's* a problem. > this is an opinion and I would respect it even > if I do not share it. Please Paul, think more about some concept that are > appearing on the web now: > > a) the notion of web service: you do a URL request and get back an answer in > XML. Do you find that a monster? No. When saying 'monster' I mean that instead of elegant and expandable core layer + some utility functions built on top of the layer, we are receiving 'handy hacks' in the core layer. <monster_example> If one get a chance to dig into internals of Tcl/Tk and Perl, there would be no question why Tcl now supports threads, but Perl still has some problems with threads. I'm not talking about the languages. I'm talking about the implementation and some design principles. Not even talking about perl 4, Perl 5 had *a lot* of things hardcoded in the core, instead of placing those things into extensions. For example, one could use read / write send / recv and sysread / sywrite, print e t.c. to work with sockets and *all* those functions were ( are? ) in the *core* perl executable ( doing more or less the same thing). Such a mess. On the opposite, the Tcl/Tk balancing between layers was *amazing*. When I first realized that Tcl/Tk ( version 7?) has: 1. Very small OS-specific C kernel for drawing windows / processing mouse/ keyboard. 2. On top of (1), some other C layer. 3. On top of (2) - Tcl layer. 4. On top of (3) - the rest ( and that 'the rest' is in Tcl! The behavior of buttons has been coded in *Tcl*, not in C ). I was realy impressed to see how could layering be done *realy* elegant, when things that should be in a core are in a core and things that should be 'extensions' - are extensions. UNIX way == pipes of components. </monster_example> Perl is monster. Tcl / Tk was not. ( Even I don't like Tcl language itself ). > Is CORBA or DCOM better? if yes why? Ghm... we should also mention RMI, I think .... I would like not to start comparing one monster to another. <aside> I would give CORBA ( and especialy EBJ ) a chance. With some ongoing marginal implementations of EBJ, there are some nice simplifications happening. EJBoss looks very interesting. </aside> In principle - I have nothing against URI's and URL's ( especialy - I have nothing against webDav. I think that could be the next amazing thing ) I just said that XSLT's 'document()' function better not to be polluted in the way you are suggesting ;-) But if it will be - I'l not cry also. I could live without or without that 'document' hack. I'm not using 'dcument' with XSLT at all. With PXSLServlet I'm bringing everything I need into one and only one and always one XML document - and then XSLT does it's job == rendering. > b) the notion of content aggregation. If a posted document is an XML > document, a fragment of this document can be aggregated by an other document > using an XPath expression (i.e using the document function as an XPath > step). XSLT is about transformations of single document ( XML tree ), but not about content management. document() function is a logical hack . Content management ( aggregation, addressing, storage, updating, versioning e t.c. et c. ) is another problem domain. Trying to turn XSLT into silver bullet for *anything* is very understandable ( because to me - XSLT is in *much* better shape than some other things ), but such an attempt already caused some absolutely useless features, bloating the engine. When it comes to merging multiple XML documents into one XML document on the fly - stylesheet becomes a mess. I think it is obvious, that having 'eval' and 'node-set' in the core is *much* closer to original XSLT purpose than getting fancy ( 'non-stradard' ) way of navigating multiple XML documents ( and their fragments ). That's the issue of taste, of course. With current XSLT extensibility features, almost everything could be done with extensions. There is actualy no need in belowed 'for' loop in XSLT, because the same functionality could be easily implemented with extension:range + extension:node-set That means if one needs to grab some part of the separate document - this also could be done with extension:give-me-part-of-the-document-or-some-data-from-database + extension:node-set. > Off course in the case of b) you can say that there are some serious > commercial problems. No. I'm talking only about the design. About balancing functionality between 'core' and 'layers'. XSLT is good in that balancing, but not perfect. I think there are some useless things in there, but 'eval' and 'node-set' are missing in the core ;-) For example. Actualy, that is all understandable. The idea was to make something for 'documents'. Unfortunately, the world is not a heap of plain XML files. Not at all, actualy. > So to conclude, it seems Paul that you do not want to drink the document() > function magic potion and that the notion of web service is more evil than > good new for you. It is nothing special for me. Some data may come from the source which is identified by URI, some could come from other source. The original purpose of XSL was to give a powerful rendering of plain text files. Since then many things have changed. XSL has been split to XSL FO and XSLT, e t.c. e t.c. > Is this what you are saying or, once again, the monster of > email misinterpretation played some of its tricks. Note: Guys from Scotland > assured me that the monster of email misinterpretation has no parenthood > relationship with the loch ness monster - the former is the bad guy and the > latter the good guy. Monsters are just funny. The good software is elegant. grep and yacc will never die, I think. Perl certainly will die, like it was with PL 1. The funny thing is that we like XSLT because of XPath part. XPath part is the only part of XSLT free of 'XML-mania'. XPath is good-old-UNIX-alike-command-line-grep-alike-beast. Small beast which requires you to type those */[] things. Verrrrrry bad for 'end-user'. Rgds.Paul. PS. Indeed, I would like to type in some belowed csh: ls / / some Instead of find . -name some XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Future XSLT expansion. ( Re: Mi, Didier PH Martin | Thread | RE: Future XSLT expansion. ( Re: Mi, Didier PH Martin |
ANN: 4XPath 0.8.3 and 4XSLT 0.8.3, Uche Ogbuji | Date | RE: Microsoft XSL and Conformance, Juergen Hermann |
Month |