RE: XSLT V 1.1

[Eckenberger Axel <Extern.Eckenberger@xxxxxxxx>]

Paul,

> -----Original Message-----
> From: Paul Tchistopolskii [mailto:paul@xxxxxxx]
> 
> > PS: ... see previous mail for further details
> > 
> > Maybe an extension to the current document function 
> > is the way forward ...
> 
> What?  *Extending* current document() ? No and no.
> It is already overloaded.

Extending it to make it simpler, while still providing all the functionality
it currently provides.

> Your .zip file contains 16 files. ( Only one XSL file ).
> 
> If the advantage of current document() shows
> itself only on 15 XML files, I don't think this 
> advantage is healthy.

Well, Jeni put it simpler ....

> >----- Original Message ----- 
> >From: Jeni Tennison <mail@xxxxxxxxxxxxxxxx>
> >
> > <class-files>
> >   <file href="class1.xml" />
> >   <file href="class2.xml" />
> >   <file href="class3.xml" />
> > </class-files>
> > 
> > <xsl:for-each select="document(class-files/file/@href)/classes/class">
> >   <xsl:sort select="@name" />
> >   ...
> > </xsl:for-each>
> 
> What is this?  This should not work in current XSLT.

This is the point I tried to prove (although a bit more elaborate)!!! This
works under the current XSLT 1.0 specification! Before you make statements
like this, read the documentation, _please_!!! 

I used 16 files as I tried to provide you with 3 use cases and an
application that uses them. Furthermore, I also described the 6 use cases I
could deduce from reading the spec and evaluated your proposal against them.
I do not negate the fact that you try to simplify the "big bad monster of
the document function" :-), but I a) cannot see the point of doing it
(althought I admit that the description in the spec is a bit difficult to
understand) and b) want to make sure taht if it has to be admended, it
supports all the existing usecases. In oposition to you I _do_ believe that
the defined usecases are valid and do provide the developer with a great
deal of freedom in the way that she/he can use the function (once they
understand it from the spec ;-), which took me a while ...).

> -----Original Message-----
> From: Paul Tchistopolskii [mailto:paul@xxxxxxx]
> 
> Please don't get me wrong here - I don't think somebody 
> will care trying to reverse-engeneer 16 files - and my point 
> is to show not only to you but also to other subscribers - 
> what it is this all about.

I don't get you wrong here and I do understand that it might be a bit of an
overkill, but the whole thing can be explained by looking at the XSL file,
the rest is just additional information to provide a working model that can
be verified.

And do not forget you asked for it ...
<quote>
> -----Original Message-----
> From: Paul Tchistopolskii [mailto:paul@xxxxxxx]
> 
> I'l be very glad to see XSL pseudo-code which works 
> with current document() but will fail with this version.
</quote>

Before you reply that it is possible with your function ...
> -----Original Message-----
> From: Eckenberger Axel [mailto:Extern.Eckenberger@xxxxxxxx]
>
> I admitt that this might also be possible with your suggestion, however I
> think that in the long-run will produce longer, and more difficult code as
> you will have nested 
> <apply-templates select="document()"/> statements.

Bye

Axel


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