Return-Path: 
 <forrest-dev-return-7954-apmail-xml-forrest-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-forrest-dev-archive@www.apache.org
Received: (qmail 88175 invoked from network); 23 Oct 2003 13:17:47 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 23 Oct 2003 13:17:47 -0000
Received: (qmail 54972 invoked by uid 500); 23 Oct 2003 13:17:00 -0000
Delivered-To: apmail-xml-forrest-dev-archive@xml.apache.org
Received: (qmail 54936 invoked by uid 500); 23 Oct 2003 13:16:59 -0000
Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:forrest-dev-help@xml.apache.org>
list-unsubscribe: <mailto:forrest-dev-unsubscribe@xml.apache.org>
list-post: <mailto:forrest-dev@xml.apache.org>
Reply-To: forrest-dev@xml.apache.org
Delivered-To: mailing list forrest-dev@xml.apache.org
Received: (qmail 54898 invoked from network); 23 Oct 2003 13:16:59 -0000
Received: from unknown (HELO main.gmane.org) (80.91.224.249)
  by daedalus.apache.org with SMTP; 23 Oct 2003 13:16:59 -0000
Received: from list by main.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1ACfKl-00018q-00
	for <forrest-dev@xml.apache.org>; Thu, 23 Oct 2003 15:16:59 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: forrest-dev@xml.apache.org
Received: from sea.gmane.org ([80.91.224.252])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 1ACfKk-00018i-00
	for <gmane-text-xml-forrest-devel@m.gmane.org>;
 Thu, 23 Oct 2003 15:16:58 +0200
Received: from news by sea.gmane.org with local (Exim 3.35 #1 (Debian))
	id 1ACfKk-0006JS-00
	for <gmane-text-xml-forrest-devel@m.gmane.org>;
 Thu, 23 Oct 2003 15:16:58 +0200
From: Nicola Ken Barozzi <nicolaken@apache.org>
Subject: Re: [RT] Validation includes and excludes
Date: Thu, 23 Oct 2003 15:14:15 +0200
Lines: 181
Message-ID: <bn8kca$nmd$1@sea.gmane.org>
References: <bn6ep4$qni$1@sea.gmane.org>
 <20031023093324.GA1369@expresso.localdomain> <bn8apl$3u2$1@sea.gmane.org>
 <20031023113310.GA14210@expresso.localdomain>
Reply-To: nicolaken@apache.org
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@sea.gmane.org
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.5) Gecko/20031013 Thunderbird/0.3
X-Accept-Language: en-us, en
In-Reply-To: <20031023113310.GA14210@expresso.localdomain>
Sender: news <news@sea.gmane.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

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