forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Brakkee <e...@brakkee.org>
Subject Re: Include mechanism for forrest...
Date Tue, 18 Oct 2005 06:52:42 GMT
Hi,

David Crossley wrote:

>erik@brakkee.org wrote:
>  
>
>>All in all, what do you think about this  proposal:
>>- extend the xdoc DTD with an include element so that includes can be used out of
the box without breaking the DTD
>>    
>>
>
>We have a policy to only include new elements to the DTD that
>are in line with XHTML2.
>
>Is there another way that your need can be addressed?
>Perhaps switch off the default validation for source docs
>that do this including (in forrest.properties).
>
>  
>

Just thinking out loud:

Switching off validation is a solution but also a problem at the same 
time because validation helps authors to create documents.
A solution whereby you could include a module locally into the DTD for 
every extension you use would be an option. In that case
however, Forrest will no longer be able to recognize which type of 
document it is reading from the DTD alone. As a result, we would
have to use another extension for documents that use an include mechanism.

The problem with this solution is a bit with extensibility. Suppose I 
have two extensions, both of which who add new elements to Xdoc, then 
each of the extensions would have their own file extension to 
distinguish them from Xdoc. However, what if I would use the two 
extensions together?

Another solution would be to have an <extension> element in the DTD with 
content ANY. Then, inside the <extension> document you can add any 
content you like, such as includes. In the internal Forrest pipeline, 
all configured extensions (forrest.properties?) would be processed and 
the 'extension' element itself would be removed at the end of 
processing. In this way, we can have an extension mechanism that has no 
overhead for extensions which are not used at all. Also, validation of 
the document would still be possible, with the exception of the content 
inside the 'extension' element. For the 'extension' element itself, we 
could define modules to include locally in the DTD, so that validation 
could even be done for the content of the 'extension' element.

To disambiguate between different extensions, each extension would have 
to use its own namespace. With this solution, multiple extensions can 
even be used together with full validation of the documents, and the 
overhead would be zero for extensions that are not used.

>>- implement the include as a thin layer on top of xinclude within Forrest, providing
a simple syntax, yet not limiting the power of xinclude.
>>    
>>
>
>I am concerned about adding extra layers of processing to meet a small need.
>Ross' idea about the internal plugin might suit.
>  
>
I don't know about this mechanism because I am relatively new to 
Forrest. Is this a 0.8 feature?
Perhaps the extension mechanism I outlined above would be useful as an 
extension mechanism for documents.

Cheers
  Erik

>-David
>  
>


Mime
View raw message