[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSLT V 1.1

Subject: Re: XSLT V 1.1
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Tue, 12 Sep 2000 11:43:30 -0700
get xml from current xsl
> >> 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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.