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
- Subject: Re: XSLT V 1.1
- From: Paul Tchistopolskii <paul at qub dot com>
- Date: Tue, 12 Sep 2000 11:43:30 -0700
- Organization: The Qub Group
- References: <44F0B703A897D311B4410008C7DF7068A1A339@exchange.stibo.dk>
- Reply-To: xsl-list at mulberrytech dot com
> >> 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