This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: XSLT V 1.1
- To: "'xsl-list at mulberrytech dot com'" <xsl-list at mulberrytech dot com>
- Subject: RE: XSLT V 1.1
- From: Eckenberger Axel <Extern dot Eckenberger at kmweg dot de>
- Date: Mon, 18 Sep 2000 11:02:08 +0200
- Reply-To: xsl-list at mulberrytech dot com
Paul,
> -----Original Message-----
> From: Paul Tchistopolskii [mailto:paul@qub.com]
>
> > 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@jenitennison.com>
> >
> > <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@qub.com]
>
> 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@qub.com]
>
> 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@kmweg.de]
>
> 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