cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Portier <>
Subject Re: xconf tool, entity resolver, and new build options
Date Thu, 22 May 2003 15:55:11 GMT

David Crossley wrote:
> Geoff, we cannot use the xmlcatalog from Ant because that
> is in ant-1.6 and cocoon is currently ant-1.5.3
> Anyway, Marc was closest to the mark with his suggestions.
> We need to hook the entity resolver up to the parser that is
> used in

thx, although I wasn't anywere near making these subtle nuances 
in ant versions

> We can re-use the resolver.jar that is shipped with Cocoon.
> I almost have it working here (he says hesitatingly) ...
> will report back soon.
> There is one issue which may cause grief. We cannot redistribute
> that DTD according to its license - we need to get "prior written
> authorization of Sun".

dear friend and colleague Bruno was actually suggesting to have 
the parser not taking the DTD into account at all

underlaying question being if we really do want to maintain local 
copies of all involved DTD's? (even apart from the licensing 
issues surrounding it, this could become a management issue?)

and while typing this I start to realize there are even more 
reasons on a technical level NOT to consider the DTD in this 
1. the DTD will not be applied to ensure valid output (the 
serializer doesn't do that)
2. the DTD will only be applied to confirm validity of the input 
which in this case might very well incomplete since we want to 
patch it anyway?
3. introducing the DTD might lead to introduction of the default 
attribute setting (which isn't wrong, but a bit more then we want 
to achieve, and getting maybe confusing for end-users)

so if we want valid docs in our proces we should have a 
<validate> after the <xpatch> anyway

to get there: not looking at the DTD could be done with

builder.setFeature("", false)

allthough the last one might be only supported by Xerces.

being really pragmatic: just dropping the DOCTYPE line in the 
input docs should achieve the same :-/

and to make it worse, Bruno just points me to this:
(license compatible)

Although I think the xsl versus xpatch discusion between gianugo 
and bertrand actually stressed the depreciation off on a 
'new/complex (xsl) syntax' versus an 'existing one in the cocoon 
so as long as the argument holds we should be brave enough to 
support our own task?


> --David

Marc Portier                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                        

View raw message