Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <45056068.1020408@apache.org>
Date: Mon, 11 Sep 2006 14:11:04 +0100
From: Ross Gardler <rgardler@apache.org>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
MIME-Version: 1.0
To: dev@forrest.apache.org
Subject: Re: xinclude
References: <6212b1d00606290824p5557e258q7d878c14d62cd89f@mail.gmail.com>
  <1151595390.8177.39.camel@localhost.localdomain>
  <Pine.LNX.4.58.0609031601400.16247@westbury.dixons.org>
  <44FB3B5C.80808@apache.org>
  <Pine.LNX.4.58.0609040814190.16247@westbury.dixons.org>
  <44FBE573.2010609@apache.org>
  <Pine.LNX.4.58.0609061454430.16247@westbury.dixons.org>
 <1157552352.8095.12.camel@localhost.localdomain>
 <Pine.LNX.4.58.0609061545440.16247@westbury.dixons.org>
 <Pine.LNX.4.58.0609061556200.16247@westbury.dixons.org>
 <44FEEBDA.8030305@apache.org>
 <Pine.LNX.4.58.0609080830220.16247@westbury.dixons.org>
 <45013DD7.4070909@apache.org>
 <Pine.LNX.4.58.0609081152340.16247@westbury.dixons.org>
 <45015229.9070400@apache.org>
 <Pine.LNX.4.58.0609110756490.22320@westbury.dixons.org>
 <450525A6.3080304@apache.org> <45052AC1.6020906@apache.org>
 <Pine.LNX.4.58.0609111227520.22320@westbury.dixons.org>
In-Reply-To: <Pine.LNX.4.58.0609111227520.22320@westbury.dixons.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Jim Dixon wrote:
> On Mon, 11 Sep 2006, Ross Gardler wrote:
> 
> 
>>>>>>A better approach would be to process the XIncludes before validation,
>>>>>>stripping off the xlmns:xi attribute from the document element and
>>>>>>replacing xi:includes with whatever they resolve to.  This should be
>>>>>>cheaper than it might seem: unless the xmlns:xi is present, the
>>>>>>document is simply handed on to the validator untouched.
>>>>>
>>>>>I can't see an easy way of doing this as, in many cases, the included
>>>>>content is generated by Forrest. In fact, this would be a problem if the
>>>>>parser were doing the includes.
>>>>
>>>>I am baffled.  How would it be a problem if the parser was doing the
>>>>XIncludes?
>>>
>>>David points out in another message that the validate-xdocs is done
>>>prior to Forrest doing any transformations on content, it only validates
>>>the *source* documents.
> 
> 
> Yes.  Now think carefully about what you are saying.  Validation is
> against the DTD, say document-v20.dtd.  This is validation of the source
> document.  As it stands, if that source document has any xs:includes in
> it, it is rejected by the validator.

Yes.

> What you are saying is that when (some?) source documents are translated
> into internal format, Forrest adds xi:includes, and the transformed
> documents would not validate. That is, Forrest's internal format is not
> compliant with document-v20.dtd.

Consider this XDoc snippet which could be a source document:

<body>
   <section>
     <title>foo</title>
     <p>blah blah blah</p>
     <xi:include src="bar/productList.xml"/>
   </section>
   ...
</body>

Now, consider that "bar/productList.xml" is generated by Forrest, 
through a query to a relational database.

If we simply "turn on" validation using the parser there xi:inlude would 
not exist since it is a dynamically created document. So that brings us 
to your proposal:

...

> A cleaner solution, which involves little work, is to add an include
> element to document-v20, which has the same attributes as xi:include.

-1

We are working towards an internal document format that is a subset of 
XHTML2. We have, for some time now, only been allowing changes to the 
XDoc DTD that conforms to XHTML2 because of this.

> Also permit a xmlns:xi attribute on the document.  

I take it you mean the namespace - in which case this should be fine.

  > Then turn on XInclusion in the parser.
> 
> Advise users that if they want to avoid validation of XIncluded XML
> (because the XML doesn't exist yet, because it isn't static) they should
> use the <include> element - which could only be used in certain places.

Since we can't have an include element this would be replaced by a 
message telling the user that if they are xi:inluding dynamic content 
they should turn off validation for those pages. Our existing validation 
exclusion code will work fine for this.

Ross