cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: XInclude processor submitted
Date Tue, 09 May 2000 13:05:39 GMT
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' 

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.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message