Re: XSLT V 1.1

[Paul Tchistopolskii <paul@xxxxxxx>]

> >> How would you solve this without the second parameter of document() ?
>
> >I think  this should be a default behavior of document( URI ).
>
> Well.  The standard says otherwise.  If you change it, you break your 1.0 style sheets.

Yes. I was wrong estimating that I can solve some of the
problems you are solving with pure XSLT. I was too naive.
( ... I'm anyway 'breaking'  my stylesheets with saxon:evaluate'
and 'xt:node-set' )

> > XSLT engine knows what is the system id of anything.xml, so it
> > should resolve the document(URI)  taking into account the
> > system id of anything.xml ( not the system id of xsl stylesheet ).
>
> Why?  You just turn the problem around.  What if you need an XML-file which is located
with the XSL file?

The URI of XSL file could be provided to the stylesheet itself by XSLT engine
( in $argv0 ). The URI of XML file ( 'argument' ) could be provided as well.

This pattern worked fine for decades. ( And is was trivially implemented
in Ux, because $argv0 was unavoidable for some *other* things. )

> I second Davids proposal that there should be a standard interface to the various URI's
present in the processor.

Because David  have not provided the particular example with 'entities,
breaking URI'  I still don't understand why  'design pattern' which currently
works for  'XSL'  will not work for 'XML'. In fact I think we are discussing
pretty much the same thing.

My solution is:

1. Provide XSL stylesheet with URI of 'XML' and 'XSL'.
2. Resolve all URI's in document() relatively to 'XML'
and 'xsl:import' 'xsl:include' relatively to 'XSL'
3. For other (weird) cases - calculate the desired
URI by yourself.

Yes, (3) requires XSL Engine  to provide 2
parameters to each stylesheet. Like :
"current-xsl" and "current-xml".

Or "$argv0" and "$argv1".  Or add 2 more functions,
like get-xsl-uri() and get-xml-uri().

2 more parameters will be better than 2 more functions,
from my point of view and will be better than current
document().

But.

*In principle* this all could be more complex.

Maybe there are some especially weird usecases
when entities 'override  the URI, but it is 'important'
to the stylesheet ( I can't believe this is the case in
the real life, but theoretically it could be, as David
says. And he is right. Maybe. I'll agree  when I'll see
a usecase. )

I don't yet understand what *current* XSLT does
in import/include when it receives such a garbage
( XSL stylesheet, composed with entities instead of
import / include mechanism ) I guess it simply
breaks. The rationale for current XSLT to break is
"don't use that weird marcroprocessor, even you
can". But if current XSLT does *not* break  with weird
'XSL'  - this means swapping 'XML' with 'XSL' ( what
I'm proposing ) will be safe.

To explain better what I'm talking about, David's
usecase of breaking XML will help. As it was
mentioned here already - there is some symmetry
between  input 'XML' and input 'XSL'. I'm just saying that
symmetry should be 'better'. ( And I still think
that resolving document() and xsl:include from the
*same* ( stylesheet ) URI is wrong idea. Even the
idea is 'standard' ).

Rgds.Paul.




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