forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Validation includes and excludes
Date Thu, 23 Oct 2003 13:14:15 GMT
Jeff Turner wrote:
> On Thu, Oct 23, 2003 at 12:30:43PM +0200, Nicola Ken Barozzi wrote:
>>Jeff Turner wrote:
>>>On Wed, Oct 22, 2003 at 07:26:24PM +0200, Nicola Ken Barozzi wrote:
>>>>I mean, why do we sometimes need to exclude validation? site.xml ... it 
>>>>should validate ok, as it has no DTD and so it should check that it's 
>>>>only well-formed...
>>><xmlvalidate> asserts that files are *valid*.  site.xml isn't, so it
>>I read here:
>> "This task checks xml files are valid (or only well formed)."
>>So I guessed that adding lenient would make it work in this case.
>>The problem is that the lenient attribute does not use simple 
>>well-formdness as a fallback in case of missing DTD but as a normal 
>>IMHO patching this task to make it check only if it's well formed if 
>>there is not DTD info would solve the problem.
> It would have to be a optional though, off by default in Ant.  Perhaps:
> <xmlvalidate ...>
>   <fallback>
>     <xmlwellformed ...>
>       <fallback>
>         <fail message="XML not wellformed or valid"/>
>       </fallback>
>   </fallback>
> </xmlvalidate>

<xmlvalidate> already checks for weldformdness (how do you write it?) 
if @lenient is false, so we would just need to do something like:

  <xmlvalidate lenient="fallback">

that makes it lenient (ie only well-formed) when the DTD spec is not 

But then we have also RNG stuff to validate... I guess we'll have to 
heavily upgrade that task to also use jing. Since Ant is in a release, I 
propose to make our own xmlvalidate extending the existing one and when 
it's working well we propose it to Ant.

>>>>I'd really like to make this simpler... maybe checking for .valignore 
>>>>files as we have .cvsignore files? Maybe putting a meta tag or a comment 
>>>>tag in the xml pages to prevent validation on them?
>>>>Till I don't see the need of these excludes I fail to decide on the 
>>>>solution... help!
>>>What's the problem?  Almost all .xml files in content/xdocs ought to
>>>validate, so having to exclude some files shouldn't be a major issue.
>>IIUC you mean that changing from the current multi-line validation 
>>settings to a single exclude property should do it?
> No, I mean I have no idea what you're on about :)  The exclude is
> specified as one comma-separated value in
> forrest.validate.xdocs.excludes=site.xml,*.dtdx.xml
> I don't see what's wrong with this existing mechanism.

With what you write above, I'm ok too.

What puzzles me is this:

# validation properties

# These props determine if validation is performed at all
# Values are inherited unless overridden.
# Eg, if forrest.validate=false, then all others are false unless set to 

# Key:
# *.failonerror=(true|false)    stop when an XML file is invalid
# *.includes=(pattern)         Comma-separated list of path patterns to 
# *.excludes=(pattern)         Comma-separated list of path patterns to 
not validate


>>I tend to agree, what got me thinking was the fact that there are so
>>many in place now. I always use the one exclude line, but I'm just one
>>>The real problem seems to be that Cocoon has bugger-all validation
>>>capabilities.  Validation would ideally be done in the pipeline, with a
>>><map:validate type="..."/> component.
>>Not really... Cocoon traverses the site, but I want to validate all xml 
>>artifacts in a project and in Forrest that are not source files.
> Yes, there's config files 'n things, but they have a well-defined
> location and should never be excluded.
>>Besides validation a sdone now is *much* faster than anything done by
> Cocoon does have a magical ability to slow things down, but in theory,
> validation in a pipeline on preparsed XML should be faster..

Well, yes and no. If you are generating the site, then


is faster than

   parse->validate + parse->generate

But if you just need to validate, then:


is faster than


and throw away the generated stuff.

Other than this, I agree that Forrest should nevertheless at some point 
have validation in the sitemaps, but ATM I'll go with what written below:

>>I'm just trying to do one step at a time and keep changes simple, so 
>>IMHO keeping external validation but with new include/exclude rules is 
>>what we need ATM.

Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

View raw message