forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
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
>>>fails.
>>
>>I read here: http://ant.apache.org/manual/OptionalTasks/xmlvalidate.html
>>
>> "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 
>>procedure.
>>
>>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 
specified.

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.properties:
> 
> 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:
http://cvs.apache.org/viewcvs.cgi/xml-forrest/src/core/fresh-site/forrest.properties?rev=1.1&content-type=text/vnd.viewcvs-markup

"
##############
# 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 
true.
#forrest.validate=true
#forrest.validate.xdocs=${forrest.validate}
#forrest.validate.skinconf=${forrest.validate}
#forrest.validate.sitemap=${forrest.validate}
#forrest.validate.stylesheets=${forrest.validate}
#forrest.validate.skins=${forrest.validate}
#forrest.validate.skins.stylesheets=${forrest.validate.skins}


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

#forrest.validate.failonerror=true
#forrest.validate.includes=**/*
#forrest.validate.excludes=
#
#forrest.validate.xdocs.failonerror=${forrest.validate.failonerror}
#
#forrest.validate.xdocs.includes=**/*.x*
#forrest.validate.xdocs.excludes=site.xml
#
#forrest.validate.skinconf.includes=${skinconf-file}
#forrest.validate.skinconf.excludes=
#forrest.validate.skinconf.failonerror=${forrest.validate.failonerror}
#
#forrest.validate.sitemap.includes=${sitemap-file}
#forrest.validate.sitemap.excludes=
#forrest.validate.sitemap.failonerror=${forrest.validate.failonerror}
#
#forrest.validate.stylesheets.includes=**/*.xsl
#forrest.validate.stylesheets.excludes=
#forrest.validate.stylesheets.failonerror=${forrest.validate.failonerror}
#
#forrest.validate.skins.includes=**/*
#forrest.validate.skins.excludes=**/*.xsl
#forrest.validate.skins.failonerror=${forrest.validate.failonerror}
#
#forrest.validate.skins.stylesheets.includes=**/*.xsl
#forrest.validate.skins.stylesheets.excludes=
#forrest.validate.skins.stylesheets.failonerror=${forrest.validate.skins.failonerror}
"

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

   parse->validate->generate

is faster than

   parse->validate + parse->generate

But if you just need to validate, then:

   parse->validate

is faster than

   parse->validate->generate

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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------



Mime
View raw message