Re: Future XSLT expansion. ( Re: Microsoft XSL and Conformance )

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