RE: XSLT V 1.1

[Eckenberger Axel <Extern.Eckenberger@xxxxxxxx>]

> -----Original Message-----
> From: Paul Tchistopolskii [mailto:paul@xxxxxxx]
> Sent: Thursday, September 14, 2000 10:52 AM
> To: xsl-list@xxxxxxxxxxxxxxxx
> Subject: Re: XSLT V 1.1
> 
> From: Eckenberger Axel <Extern.Eckenberger@xxxxxxxx>
> 

> I will repeat. When you have XML and XSL 'without files' how can 
> document() with 2 parameters help you ?

It doesn't. But ... see below ...

> I suggest re-reading the thread ( should be easy, because 
> all the letters with this subject are related to document()
> with 2 arguments ).

I read the thead !!! And in the discussion it was suggested (I think it was
David) that if you reduce the document function to have one argument you
will need a function of obtaining the uri for a node in order to resolve
relative paths and I was trying to point out that there would be other uses
for this.

> I don't need to know this fact. XSLT engine has to ( and 
> knows  it, actually.) I suggest re-reading the thread. 
> 
> What is your point? 

See reply to your points ...

> My points are ( sorry for typing it all once again ):
> 
> 1. document with 2 arguments is weird. It is a 
> suspicious workaround for not-existent usecases
> which could be solved without the second 
> argument. 

This may be true, however the specification has to cater for a broad range
of use cases, even wired ones in some cases (even those where you have no
files and the xsl processor therefore cannot determine the location of a
relative path, rant ... ;-). My argumentation is not so much against the
number of arguments, but the way of how you try to solve it ---> reply to
point 2.
 
> 2. instead of using document with 2 arguments, 
> XSLT engine should resolve document( relative-URI )
>  taking into account the URI of  'XML input'
> ( currently document() is resolving the relative URI 
> taking into account the URI of XSL stylesheet -
> this was just a mistake , I think).

This _would_ break the case where you have a stylesheet stored on file
(constant) and you use it to transform an in-memory xml document (variable),
e.g. containing vaiable data obtained from a database query. And precisely
this is my point ... following your suggestion this operation would no
longer be possible, as the xml document does not have a URI and therfore
relative paths cannot be resolved.

> 3. For other ( I think weird and hypothetical, but maybe 
> possible - depends on David's answer ) cases when 
> document() wants to read something 'tricky-relative' -
> some other workarounds could be used. Like providing 
> the stylesheet with $argv0. For example for those who 
> for some ( strange )  reasons want  to address  
> XML files  relatively to XSL stylesheet, but not 
> relatively to XML input. 

Again this will only work if you start the xml parser from a command line,
but if you use it in a COM environment you don't and therefore it is
impossible to use the $argv0 mechanism.
 
> This will allow to simplify semantics of document() 
> function *significantly* without considerable loss 
> of functionality that current document() provides.

As I just showed your simplification _will_ rule out some use cases, and as
these are IMHO are less hypothetical than you think and they have to be
provided for.

> H I S T O R Y.
> 
---------------- read but still snip ------------------------
> 
> Rgds.Paul.
> 
> PS. 
> The same could be done for key() function, but I'll 
> better not to start with key() before understating 
> what happens with document().

I honestly could not comment on the key thingy, as I haven't looked into
that, but as far as I gathered is nobody quite happy with it.

I do understand your intention to simplify the document function, however
this simplification should not be allowed to break any existing stylesheets
(Thorbjørn's argument) and it should not leave out some functionality that
is not uncommon, at least in the MS world (my argument). Further, I _do_
agree that the document function is a bit strange and I do not claim that I
have understood the spec completely, however I can see that your suggestions
will provide some difficulties for people who use XML the way I am doing it
in the moment.

Bye Axel


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