forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Noels <>
Subject Re: [RT] Entities in XML docs
Date Fri, 27 Dec 2002 21:21:56 GMT
Stefano Mazzocchi wrote:

(comments & snips)

>> This method has the limitation that values cannot be included halfway 
>> inside an
>> attribute.  Eg, we couldn't have
>> <s1 title="The <xi:include href="#xml4j"/> project">
>>   ...
>> </s1>
> This is actually a good limitation because it emerges a design pattern 
> for schema creation: don't use attributes for anything that might 
> require token expansion.

Yep. Layman's terms: if you need structure inside, don't use attributes.

>  1) provide a namespace-like prefix for variables
>  example
>    <p>Copyright ${char:copy} ${project:year} ${project:owner}. All 
> Rights Reserved.</p>
>  then we can associate different fragment collections, some of which can 
> be inherited across projects.
>  NOTE: the ${char:copy} will be *MUCH* handy when we get rid of DTDs

Please expand? I don't parse that sentence...

>  2) make the token expander copy-over those variables that are not found.
>  This allows us to avoid the need to escape stuff since normally 
> variable names don't include a namespace-like prefix and if they do, 
> they can be escaped with normal CDATA sections.
>> Are there any more options I haven't thought of?
> Use Ant filtering. That's how this works on Cocoon right now, but it 
> requires ant to preprocess all xdocs and this is not an optimal solution 
> but a hacky one.

We are trying to shift away from Ant dependencies, since these won't 
work in a webapp context. We have been using Ant-filtered copying but it 
bite us already.

The 'namespace' thing might as well be expanded to support i18n, I 
assume? Since this touches content and we don't want to put anything in 
the way (nor do we support anything special) for i18n, we must be sure 
this won't clash with multi-lingual sites neither.

If anyone wants to play with a multilingual collection, check out

This Transformer should be at the end of the pipeline, since a skin 
could also contain shortcuts.

>> My current preference is to go with 3.2, and implement it with 
>> InputModules, the
>> same way LinkRewriterTransformer works.  Using XInclude would involve 
>> less
>> coding, but the DTD problems would be too horrible..
> Like I showed above, I do see in the future the need for forrest to 
> support xinclude of document fragments, but this is a separate concern 
> from the inclusion of string tokens.

I wouldn't mind them containing document fragments, if we are aware of 
possible issues 
Consider them being entities on steroids.

Steven Noels                  
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at    
stevenn at                stevenn at

View raw message