RE: XSLT V 1.1

> 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' )

Extensions do not break conformance.  You just tie yourself to the particular processor you use.


> > 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.

Yes.  Certainly.  Except that it doesn't in XSLT 1.0.  The current semantics for document(a,b) does cover these cases completely.

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

One of my most frequent annoyances about the argv[0] mechanism is that you get either the full path of the processor or the command name the user typed.  Either has disadvantages.  What is wrong with the current approach except being different to what you know already?


> 
> > 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.

Not completely.  You are trying to fix something that ain't broken.  And doing it in an incompatible manner :-(

-- 
  Thorbjørn Ravn Andersen             "...and...Tubular Bells!"
  http://bigfoot.com/~thunderbear


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