cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject Re: XInclude processor submitted
Date Thu, 11 May 2000 03:30:36 GMT
On Tue, 9 May 2000, Stefano Mazzocchi wrote:

> Donald Ball wrote:
> > 
> > I got sick of not having any generic inclusion functionality in cocoon1 so
> > I backported the XInclude filter from cocoon2 to be a new processor in
> > cocoon1. 
> 
> Uh, great. [BTW, donald, consider kicking Pier in his skinny ass or
> Cocoon2 will never see the light :)]
> 
> > It works as one would expect, with the following caveats:
> > 
> > 1. Namespace support is a bit kludgy since the DOM2 namespace API routines
> > don't appear to be working properly with Xerces (!) and I had to write my
> > own. Why, oh why is this? Is there a feature one must turn on?
> 
> Probably so. Mike, any help?
>  
> > 2. When resolving relative locations, if an XMLBase attribute is active in
> > the current context, the file will be resolved against that URL, otherwise
> > the file will be resolved against the location of the source resource in
> > the local filesystem, not the requested URIspace. discussion on this is
> > welcome.
> 
> take a look at XSLTProcessor to see how URI relative locations are
> handled, also you can use the following function
> 
>  String Util.getRootpath(request, context);
> 
> to get access to the root path in a servlet API compatible way across
> containers. (modulo bugs)

Er, getRootpath is just a wrapper for getRealPath("/"). I think want to be
using getBasepath (that's what I am doing, anyway). It works as expected,
at least on JServ. The only real discussion I can foresee here is if
included relative URLs are relative to the request URLspace or the local
filespace. I favor the latter, but one could argue a case for the former.
Probably the XInclude draft should include some mention of this.

> > 3. I haven't read the xpointer or xlink specs very carefully and the
> > xinclude spec is internally inconsistent. _my_ implementation of an
> > xpointer parser operates on urls like this:
> > 
> > href="foo.xml#xptr(/root/child)"
> > 
> > corrections are welcome.
> 
> The above is valid, given the latest W3C WD, but may create problems.
> Here's the explaination:
> 
> So, my suggestion would be to change "xptr" to "xpointer" even if more
> verbose and try to be as compliant as possible (Scott, does Xalan
> support the XPointer extended XPath specification?)

done.

> > 4. circular inclusion checking is not supported.
> 
> I would not care about this at this time, but in the future we should,
> add it as a "FIXME" comment in the file.

actually, nested inclusions won't work at all right now in the cocoon1
version, now that i think about it, unless the included document is coming
from cocoon and xinclude processing is turned on. might should figure out
a way around that, but then again, hopefully xerces will be doing this
internally before too long.

> > 5. caching is effectively disabled (this should be relatively easy to fix
> > though).

that's already fixed.

> > all that aside, i think this is a pretty handy module. give it a spin if
> > you have the time so we can see how portable it is.
> 
> Sounds awesome.

standing on the shoulders of giants, that's me.

- donald


Mime
View raw message