Re: XSLT V 1.1

Subject: Re: XSLT V 1.1
From: Paul Tchistopolskii <paul@xxxxxxx>
Date: Tue, 12 Sep 2000 04:09:32 -0700
From: David Carlisle <davidc@xxxxxxxxx>

> > 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 ).
> 
> but the XML document may be spread over many different URI (via external
> entities)

I don't understand what is a problem. I'm dumb and I don't understand 
things until I see the example.

I have been provided with the example. I answered : "for this example, 
changing the deafult behavior of XSLT engine to something 
natural and easy to understand - should work".

Now you are saying that "there is another example, which breaks
your solution". 

What is your example?

> If you want to get rid of the second argument of document() then xpath
> needs functions to return the URI of a node as a string and a function
> that takes two strings, a base URI and a URI reference and returns
> the resulting URI. (This latter function is possibly writable in XSLT,
> but not very simply, so having at as a function would help)
> 
> then
> document("xxxx", node) would be more or less
> document(uri-resolve("xxx",base-uri(node)))

I think those lost souls who are trying to use XSLT to process
bunch of  XML files 'tied' with weird XML built-in macroprocessor
in some strange way ( especially if they are using proposed 
runtime-generation of the stylesheets ;-) will  *anyway* get 
some trouble earlier of later. Writing the uri-resolve function 
should be a not a big deal to them, because they are gods. ;-)

I just ( still ) think the XSLT core should not be polluted with this shorthand.

Rgds.Paul.

PS. I really don't understand you. 

XSLT transformation has '2 input's'
    XML and XSL.

What I'm saying is that to resolve document(URI) the system should use 
not 'XSL' ( like it does now ) but 'XML'.  XSL could be as well "spread over 
many different URI" .  Somehow it is not a problem for 'XSL'. Why it should 
become  a problem  for 'XML' ? Well ... I really don't understand something, 
it is 4 o'clock in the morning here ... ;-)



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


Current Thread