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

RE: Setting Base URL For Resolivng xsl:include/xsl:imp

Subject: RE: Setting Base URL For Resolivng xsl:include/xsl:import
From: "Michael Kay" <mhk@xxxxxxxxx>
Date: Fri, 21 May 2004 16:34:09 +0100
xsl base url
Yes, it should work the way you describe it. I can't see any reason from
this description why it isn't working.

Michael Kay  

> -----Original Message-----
> From: Eliot Kimber [mailto:ekimber@xxxxxxxxxxxxxxxxxxx] 
> Sent: 21 May 2004 12:52
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject:  Setting Base URL For Resolivng xsl:include/xsl:import
> 
> This may be a Saxon-specific question but I think it should 
> be a general 
>   XSLT question.
> 
> What I'm trying to do is enable the direct processing of XSLT style 
> sheets that are stored in a versioning repository that provides HTTP 
> access to versions of files. As part of this system, one uses 
> relative 
> URLs in documents to point to other files. At processing time you set 
> the resolution base (e.g., <base> in HTML) to set the appropriate 
> resolution context.
> 
> For example, in an XSLT document I might have a link like this:
> 
>    <xsl:import href="res_000000002/onSnapshot"/>
> 
> This is a relative URL that, in my repository, resolves to a specific 
> version based on the directory the URL fragment is resolved against.
> 
> To run a style sheet with Saxon 6.5.2 I can use a command 
> line like this:
> 
> saxon -o test.html 
> http://localhost:9090/br_00001/snapshot_0002/ver_00003 
> http://localhost:9090/br_00002/snapshot_0005/ver_00008
> 
> Where "http://localhost:9090/br_00002/snapshot_0005/ver_00008" is the 
> URL of the XSLT style sheet with the above import statement. 
> This works 
> for a single-file style sheet but not if there are includes 
> or imports 
> because the relative URLs are not resolved (in fact, I don't see any 
> attempt to resolve the include in my server log).
> 
> My expectation was that the import statements would be 
> resolved relative 
> to the URL of the style sheet, in this case producing the 
> effective URL:
> 
> http://localhost:9090/br_00002/snapshot_0005/res_000000002/onSnapshot
> 
> However, it appears that this is not case.
> 
> My questions:
> 
> 1. Was my expectation justified or have I misunderstood how URL 
> resolution works generally or in XSLT or in Saxon?
> 
> 2. Is there a general way to establish the URL resolution 
> base in XSLT 
> so that I would get the behavior I expected? In the context of my 
> repository I could, for example, set an attribute on the StyleSheet 
> element as I serve the XSLT document out, although I would 
> prefer to use 
> a command-line option. That is, as a matter of design 
> principle, I want 
> my repository to have know as little as possible about the details of 
> the data it is serving out--my hope being that if tools use standard 
> HTTP mechanisms everything "just works".
> 
> Reading the Saxon docs I see that I could implement my own 
> URL resolver 
> which I'm sure would solve the problem but my hope was that I could 
> enable the direct use of style sheets out of my repository by 
> unmodified 
> XSLT processors.
> 
> Thanks,
> 
> Eliot
> -- 
> W. Eliot Kimber
> Professional Services
> Innodata Isogen
> 9030 Research Blvd, #410
> Austin, TX 78758
> (512) 372-8122
> 
> eliot@xxxxxxxxxxxxxxxxxxx
> www.innodata-isogen.com

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.