XInclude processor submitted

[Donald Ball <ba...@webslingerZ.com>]

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

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.

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.

4. circular inclusion checking is not supported.

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

6. CDATA parsing is not supported.

7. Xerces always complains that it can't load a schema for the included
documents, even though validation is turned off. suggestions welcome.

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.

- donald

Re: XInclude processor submitted

[Stefano Mazzocchi <st...@apache.org>]

Donald Ball wrote:

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

The whole mapping point is useless until we finally find a stable
Servlet platform.

I wish we just had one servlet platform :/
 
> > > 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.

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

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

Don't fool me, man, you wrote more code than I did for this project :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

Re: XInclude processor submitted

[Donald Ball <ba...@webslingerZ.com>]

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

Re: XInclude processor submitted

[Stefano Mazzocchi <st...@apache.org>]

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)

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

The XInclude WD is orthogonal to the syntax used to reference the markup
to include, but it states that the XPointer spec rules this.

The XPointer WD (19991206) states that an XPointer location must have
the form

[1]  XPointerFragID ::=  Name '|' ChildSeq '|' GeneralFragmentPart+ 
[2]  ChildSeq ::=  '/1' ('/' [0-9]*)* | Name ('/' [0-9]*)+ 
[3]  GeneralFragmentPart ::=  'xpointer' '(' XPointerExpr ')' 
                              | Scheme '(' SchemeSpecificExpr ')' 
[4]  Scheme ::=  QName - 'xpointer' 
[...skipped...]

the following locations

  a) href="source.xml#title"
  b) href="source.xml#title/3/8/3"
  c) href="source.xml#xpointer(...)"
  d) href="source.xml#cocoon(...)"
  e) href="source.xml#xptr(...)"

are _all_ valid in respect of the XPointer WD.

However, a _real_ XPointer processor should react on xpointer() since
this is the normative name used to indicate that what's contained inside
the parenthesis is valid XPointer-extended XPath syntax. (XPath is
extended by XPointer to allow ranges).

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?)
 
> 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.
 
> 5. caching is effectively disabled (this should be relatively easy to fix
> though).
> 
> 6. CDATA parsing is not supported.
> 
> 7. Xerces always complains that it can't load a schema for the included
> documents, even though validation is turned off. suggestions welcome.
> 
> 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.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------