cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: [RT] Implementation of VPCs and "multi-relative" source resolving (long)
Date Wed, 17 Nov 2004 11:18:39 GMT
Carsten Ziegeler wrote:

>Sylvain Wallez wrote: 
>It seems to me that this is the right approach - there is no different from the user pov
in using vpc or usual components, which is great! So: +1


>Only one question:
>>The last source-resolving problem is related to URIs that may be present in the SAX
stream, e.g. XInclude URIs. What are they relative to?
>Hmm, aren't they always relative to the sitemap where the component is used?

The problem is *which* component and *which* sitemap.

<map:generator name="file+include">
  <map:parameter name="caller-src" value="{absolutize:{src}}"/>
  <map:generate src="{caller-src}"/>
  <map:transform type="xinclude"/>

The caller-src file contains <xi:include> elements with relative URIs. 
What base URI should the xinclude transformer use?

If the "file+include" generator is used in a subsitemap, the component 
is the VPC used in that subsitemap. Now the xinclude transformer is also 
a component, which is used in the sitemap defining the VPC.

So what is the relative context for URIs flowing in the SAX stream that 
is handled by xinclude?

>>My feeling here is that we need to distinguish for a single VPC the base URI used
to resolve URIs within the setup phase (i.e. "src" and <map:parameter>) and the base
URI used to resolve URIs during the processing phase.
>>That could be achieved using an additional attribute on the component declaration,
i.e. in the above example something like
>><map:generator name="foo" stream-uris-base="local|caller">
>I have the feeling that we don't need this as such uris are always resolved relative to
the current sitemap. If you are building a pipeline, you don't have to know where the vpc
is defined. So, you build your "content" or your sax streams based on the information (location)
you definitly know: the location of the "current" sitemap.

Yeah, but there are several "current" sitemaps. And things get worse 
when a you have a hierarchy of subsitemaps, e.g. SitemapA > SitemapB > 
SitemapC and a statement in SitemapC uses a VPC defined in SitemapB 
which in turn uses a VPC defined in SitemapA.

What does "current" mean in this scenario?


Sylvain Wallez                                  Anyware Technologies 
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

View raw message