You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@forrest.apache.org by Jim Dixon <jd...@dixons.org> on 2006/09/03 17:17:34 UTC
xinclude
On Thu, 29 Jun 2006, Thorsten Scherler wrote:
> Have a look at
> http://cocoon.apache.org/2.1/userdocs/xinclude-transformer.html
> and add xmlns:xi="http://www.w3.org/2001/XInclude" to the document tag
> like:
> <document xmlns:xi="http://www.w3.org/2001/XInclude">
Has anyone been able to get this working with Forrest? I have followed
their instructions closely but it appears that the transformed file
doesn't get passed on.
-- sitemap.xmap ---------------------------------------------------------
<?xml version="1.0"?>
<map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
<map:components>
<map:transformers default="xslt">
<map:transformer name="xinclude"
src="org.apache.cocoon.transformation.XIncludeTransformer"/>
</map:transformers>
</map:components>
<map:pipelines>
<map:pipeline>
<map:match pattern="eg/logMeIn.xml">
<map:generate src="eg/logMeIn.xml"/>
<map:transform type="xinclude"/>
<map:serialize type="xml"/>
</map:match>
</map:pipeline>
</map:pipelines>
</map:sitemap>
-- logMeIn.xml ----------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
<document xmlns:xi="http//www.w3.org/2001/XInclude">
<header><title>logMeIn</title></header>
<body>
<source>
<xi:include parse="text" href="eg/foo.txt"/>
</source>
</body>
</document>
-------------------------------------------------------------------------
foo.txt is just a line of nonsense.
Cocoon returns:
-------------------------------------------------------------------------
Message: Resource Not Found
Description: The requested resource "/eg/logMeIn.html" could not be found
Sender: org.apache.cocoon.servlet.CocoonServlet
Source: Cocoon Servlet
-------------------------------------------------------------------------
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
Jim Dixon wrote:
> On Mon, 4 Sep 2006, Ross Gardler wrote:
>
>
>>>My only use of XInlude appears above. In logMeIn.xml I
>>>
>>>(a) add an xmlns:xi attribute to the document element
>>>(b) add the xi:xinclude element
>>>
>>>Is either incorrect? Is there something else I should be doing?
>>
>>No that is fine.
...
>
> Well, it doesn't cause a problem if you do a 'forrest run', but if
> you do a 'forrest site', it fails:
> ------------------------------------------------------------------------
> validate-xdocs:
> /home/j2ee/jappgen/src/documentation/content/xdocs/eg/logMeIn.xml:4:54:
> Attribute "xmlns:xi" must be declared for element type "document".
> /home/j2ee/jappgen/src/documentation/content/xdocs/eg/logMeIn.xml:13:73:
> Element type "xi:include" must be declared.
> /home/j2ee/jappgen/src/documentation/content/xdocs/eg/logMeIn.xml:13:82:
> The content of element type "source" must match
> "(strong|em|code|sub|sup|br|img|icon|acronym|map|a)".
> ------------------------------------------------------------------------
>
> Now I'm hoping that there is a simple workaround that I am missing but ...
"forrest run" does not validate the sources, whereas forrest site does.
Hence this "error".
You can work around this by turning off validation for either all the
files or just the ones that use xinclude. See the validation related
properties in default.forrest.properties and override the relevant
values in your projects forrest.properties (or user, or site properties
if more appropriate).
Ross
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
On Mon, 11 Sep 2006, David Crossley wrote:
> There are two different situations where xml is parsed.
>
> One situation is the Cocoon/Forrest processing of xml contnet.
>
> The other situation is the 'forrest validate-xdocs' target.
> This latter is an Ant target. See $FORREST_HOME/main/targets/validate.xml
> This uses the Ant task "xmlvalidate". This can set "features"
> of the parser.
> See http://ant.apache.org/manual/OptionalTasks/xmlvalidate.html
>
> If you can find a feature about expanding included xml before
> validating, then we can can declare that feature.
> http://xerces.apache.org/xerces2-j/features.html
http://apache.org/xml/features/xinclude
Defaults to false. Needs to be true.
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by David Crossley <cr...@apache.org>.
There are two different situations where xml is parsed.
One situation is the Cocoon/Forrest processing of xml contnet.
The other situation is the 'forrest validate-xdocs' target.
This latter is an Ant target. See $FORREST_HOME/main/targets/validate.xml
This uses the Ant task "xmlvalidate". This can set "features"
of the parser.
See http://ant.apache.org/manual/OptionalTasks/xmlvalidate.html
If you can find a feature about expanding included xml before
validating, then we can can declare that feature.
http://xerces.apache.org/xerces2-j/features.html
-David
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
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
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
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.
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.
Forrest DOES NOT VALIDATE the internal format.
Nothing that I have said has anything to do with the internal format.
If Forrest were to turn on XInclusion during the validation process,
this would have no effect whatsoever on internal processing, because
what is being validated is the source document. It would, however,
remove xi:includes and replace them with what they are referencing,
and then validate the result. This is exactly what users expect.
> > This means that if a source document XIncludes another source document
> > that is available statically on disk/network, as in your use case, then
> > the above will work OK.
> >
> > However, if a source document includes source content that is
> > dynamically generated, for example, pulled from a database/RSS Feed/Jira
> > instance etc. then we would have to fire up Forrest to generate these
> > sources. If we are validating source documents before we fire up Forrest
> > we end up in a catch 22.
No more so than is already the case. At the beginning of this thread I
was trying to use xi:include to include straight text. I got this to work
with 'forrest run' by properly declaring xmlns:xi in the document element.
But I couldn't get by 'forrest site' without modifying the DTD. Anyone
XIncluding dynamic content would already have the same experience: they
could only get through validation by either disabling validation for
documents using XInclude or by defining a new DTD which includes
xi:include elements. The former means that the end document is just not
validated, which for some users will be a serious problem. The latter is
a pain in the neck and doesn't comply with XML standards. It only works,
insofar as it does, because internally Forrest ignores the augmented DTD,
the one declaring xi:include elements.
> > One solution would be to fire up a running instance of Forrest (aka
> > forrest run) and have Xerces validate the xincludes by retrieving them
> > from the running instance of Forrest. But this really is clumsy and I
> > would guess non-trivial.
> >
> > My point is, any solution that is created to better support the first
> > use case (including static content) must also work in the second use
> > case (including dynamic content).
>
> Let me clarify so as not to discourage your hunt for a solution...
>
> Any solution would need to work alongside a solution that works for the
> dynamically generated content stuff. Personally, I think being able to
> turn off validation on certain pages, as is currently the case, is just
> fine.
A cleaner solution, which involves little work, is to add an include
element to document-v20, which has the same attributes as xi:include.
Also permit a xmlns:xi attribute on the document. Internally Forrest
would replace <include> elements with <xi:include> elements, preserving
the attributes.
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.
If they want validation, they would use the <xi:include> element, which
XML allows to be used much more widely.
In either case anyone wanting to use XInclude would have to add the
xmlns:xi attribute to the document element.
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Jim Dixon wrote:
>
>> On Fri, 8 Sep 2006, Ross Gardler wrote:
>>
>>
>>>> I've thought about this a bit more. One of the problems here is that
>>>> adding xi:include elements has unexpected results.
>>>>
>>>> If the DTD is extended as above, then the validator will, I think, not
>>>> check beyond the xi:include element, and so a document may validate
>>>> even though what is being XIncluded is nonsense. I can write
>>>> <p><xi:include href="rubbish.xml"/></p>
>>>> and validation will succeed, because the xi:include element has the
>>>> pattern required by the DTD even though rubbish.xml isn't XML at all
>>>
>>>
>>> Good point.
>>>
>>>
>>>> The expected behavior is that the validator recognizes that what is
>>>> being
>>>> XIncluded is XML (as it is by default) and goes through to validate
>>>> that
>>>> as well, silently replacing the xi:include element with whatever is
>>>> XIncluded. I think that some parsers do this - perhaps only if an
>>>> option is set - but most don't.
>>>
>>>
>>> Does Xalan do it? This is the default parser for Forrest. A healthy
>>
>>
>>
>> Uhm, do you mean Xerces? From what I can see Xalan is unaware of
>> XIncludes.
>
>
> Yes, I often get Xerces and Xalan names mixed up, sorry.
>
>>>> 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.
>
> This means that if a source document XIncludes another source document
> that is available statically on disk/network, as in your use case, then
> the above will work OK.
>
> However, if a source document includes source content that is
> dynamically generated, for example, pulled from a database/RSS Feed/Jira
> instance etc. then we would have to fire up Forrest to generate these
> sources. If we are validating source documents before we fire up Forrest
> we end up in a catch 22.
>
> One solution would be to fire up a running instance of Forrest (aka
> forrest run) and have Xerces validate the xincludes by retrieving them
> from the running instance of Forrest. But this really is clumsy and I
> would guess non-trivial.
>
> My point is, any solution that is created to better support the first
> use case (including static content) must also work in the second use
> case (including dynamic content).
Let me clarify so as not to discourage your hunt for a solution...
Any solution would need to work alongside a solution that works for the
dynamically generated content stuff. Personally, I think being able to
turn off validation on certain pages, as is currently the case, is just
fine.
Ross
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
Jim Dixon wrote:
> On Fri, 8 Sep 2006, Ross Gardler wrote:
>
>
>>>I've thought about this a bit more. One of the problems here is that
>>>adding xi:include elements has unexpected results.
>>>
>>>If the DTD is extended as above, then the validator will, I think, not
>>>check beyond the xi:include element, and so a document may validate
>>>even though what is being XIncluded is nonsense. I can write
>>> <p><xi:include href="rubbish.xml"/></p>
>>>and validation will succeed, because the xi:include element has the
>>>pattern required by the DTD even though rubbish.xml isn't XML at all
>>
>>Good point.
>>
>>
>>>The expected behavior is that the validator recognizes that what is being
>>>XIncluded is XML (as it is by default) and goes through to validate that
>>>as well, silently replacing the xi:include element with whatever is
>>>XIncluded. I think that some parsers do this - perhaps only if an
>>>option is set - but most don't.
>>
>>Does Xalan do it? This is the default parser for Forrest. A healthy
>
>
> Uhm, do you mean Xerces? From what I can see Xalan is unaware of
> XIncludes.
Yes, I often get Xerces and Xalan names mixed up, sorry.
>>>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.
This means that if a source document XIncludes another source document
that is available statically on disk/network, as in your use case, then
the above will work OK.
However, if a source document includes source content that is
dynamically generated, for example, pulled from a database/RSS Feed/Jira
instance etc. then we would have to fire up Forrest to generate these
sources. If we are validating source documents before we fire up Forrest
we end up in a catch 22.
One solution would be to fire up a running instance of Forrest (aka
forrest run) and have Xerces validate the xincludes by retrieving them
from the running instance of Forrest. But this really is clumsy and I
would guess non-trivial.
My point is, any solution that is created to better support the first
use case (including static content) must also work in the second use
case (including dynamic content).
Ross
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
On Fri, 8 Sep 2006, Ross Gardler wrote:
> > I've thought about this a bit more. One of the problems here is that
> > adding xi:include elements has unexpected results.
> >
> > If the DTD is extended as above, then the validator will, I think, not
> > check beyond the xi:include element, and so a document may validate
> > even though what is being XIncluded is nonsense. I can write
> > <p><xi:include href="rubbish.xml"/></p>
> > and validation will succeed, because the xi:include element has the
> > pattern required by the DTD even though rubbish.xml isn't XML at all
>
> Good point.
>
> > The expected behavior is that the validator recognizes that what is being
> > XIncluded is XML (as it is by default) and goes through to validate that
> > as well, silently replacing the xi:include element with whatever is
> > XIncluded. I think that some parsers do this - perhaps only if an
> > option is set - but most don't.
>
> Does Xalan do it? This is the default parser for Forrest. A healthy
Uhm, do you mean Xerces? From what I can see Xalan is unaware of
XIncludes.
> warning in the docs and output of the validate task may be sufficient
> for those using a different parser.
I have only skimmed the Forrest build files but Xerces must be handling
XInclusion, because after all Forrest works. If I XInclude foo.txt in
a document, then its contents appear on the page fetched by my browser.
> > 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?
Some people build XML documents by writing chapters or sections separately
and then XIncluding them into one master document. That is, the top-level
document consists of a preamble followed by a series of xi:includes.
This is quite a sensible approach in many circumstances. But if you do
this in Forrest using a DTD modified along the lines that I have taken, it
means that you can't actually validate the document, because the
validating parser will just check that the xi:includes in the top-level
document are permitted, find that they are, and then go on, ignoring the
contents of the chapters/ sections.
To make this particular example (XIncluded sections) work, you would have
added xi:include to local.sections in the DTD. However, anyone new to
Forrest but familiar with XInclude will expect to be able to use
xi:include in many places.
You can handle this with complex DTDs or by writing XSLT scripts to
replace the xi:includes with what they represent. But this is perverse.
Think C: you don't change the grammar of C to explicitly recognize
#includes; you have a preprocessor that handles the inclusion and then
you parse what comes out of the preprocessor.
This is exactly how XIncludes should be handled: you make a pass that
dereferences the xi:includes, then you validate the output XML against
the DTD (one with no xi:includes in it).
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
Jim Dixon wrote:
> On Fri, 8 Sep 2006, Ross Gardler wrote:
>
>
>>>-------------------------------------------------------------------------
>>><!ENTITY % local.inline "|xi:include">
>>><!ENTITY % document PUBLIC
>>> "-//APACHE//ENTITIES Documentation V2.0//EN"
>>> "document-v20.dtd">
>>>%document;
>>>
>>><!ATTLIST document
>>> xmlns:xi CDATA #FIXED "http://www.w3.org/2001/XInclude"
>>>
>>><!ELEMENT xi:include EMPTY>
>>><!ATTLIST xi:include
>>> parse (text|xml) "xml"
>>> href CDATA #REQUIRED
>>> encoding CDATA #IMPLIED
>>>
>>>-------------------------------------------------------------------------
>>>
>>>This works for my purposes. I enable XInclusion by using this doctype
>>>instead of document-v20.dtd.
>>>
>>>If this were to be done as a patch, I suppose the patch would introduce
>>>a new doctype V2.1, with the xi:include element moved into what would now
>>>be document-v21.mod. This would be added to catalog.xcat.
>>
>>I don't think we need to create a version 2.1 for this to be honest. I
>>know we *should* but it is an optional element that is 100% backward
>>compatible.
>>
>>Can we just slip it in without causing any upset? Naughty I know, but I
>>don't have the time to do a "proper job" on this.
>>
>>
>>>The exact place(s) where the xi:include element would be permitted might
>>>be an issue to some. I would add it to link-content.mix.
>
>
> I've thought about this a bit more. One of the problems here is that
> adding xi:include elements has unexpected results.
>
> If the DTD is extended as above, then the validator will, I think, not
> check beyond the xi:include element, and so a document may validate
> even though what is being XIncluded is nonsense. I can write
> <p><xi:include href="rubbish.xml"/></p>
> and validation will succeed, because the xi:include element has the
> pattern required by the DTD even though rubbish.xml isn't XML at all
Good point.
> The expected behavior is that the validator recognizes that what is being
> XIncluded is XML (as it is by default) and goes through to validate that
> as well, silently replacing the xi:include element with whatever is
> XIncluded. I think that some parsers do this - perhaps only if an
> option is set - but most don't.
Does Xalan do it? This is the default parser for Forrest. A healthy
warning in the docs and output of the validate task may be sufficient
for those using a different parser.
> 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.
Ross
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
On Fri, 8 Sep 2006, Ross Gardler wrote:
> > -------------------------------------------------------------------------
> > <!ENTITY % local.inline "|xi:include">
> > <!ENTITY % document PUBLIC
> > "-//APACHE//ENTITIES Documentation V2.0//EN"
> > "document-v20.dtd">
> > %document;
> >
> > <!ATTLIST document
> > xmlns:xi CDATA #FIXED "http://www.w3.org/2001/XInclude"
> >
> > <!ELEMENT xi:include EMPTY>
> > <!ATTLIST xi:include
> > parse (text|xml) "xml"
> > href CDATA #REQUIRED
> > encoding CDATA #IMPLIED
> >
> > -------------------------------------------------------------------------
> >
> > This works for my purposes. I enable XInclusion by using this doctype
> > instead of document-v20.dtd.
> >
> > If this were to be done as a patch, I suppose the patch would introduce
> > a new doctype V2.1, with the xi:include element moved into what would now
> > be document-v21.mod. This would be added to catalog.xcat.
>
> I don't think we need to create a version 2.1 for this to be honest. I
> know we *should* but it is an optional element that is 100% backward
> compatible.
>
> Can we just slip it in without causing any upset? Naughty I know, but I
> don't have the time to do a "proper job" on this.
>
> > The exact place(s) where the xi:include element would be permitted might
> > be an issue to some. I would add it to link-content.mix.
I've thought about this a bit more. One of the problems here is that
adding xi:include elements has unexpected results.
If the DTD is extended as above, then the validator will, I think, not
check beyond the xi:include element, and so a document may validate
even though what is being XIncluded is nonsense. I can write
<p><xi:include href="rubbish.xml"/></p>
and validation will succeed, because the xi:include element has the
pattern required by the DTD even though rubbish.xml isn't XML at all
The expected behavior is that the validator recognizes that what is being
XIncluded is XML (as it is by default) and goes through to validate that
as well, silently replacing the xi:include element with whatever is
XIncluded. I think that some parsers do this - perhaps only if an
option is set - but most don't.
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.
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
(I'm moving this to the dev list, now we got past user issues)
Jim Dixon wrote:
> On Wed, 6 Sep 2006, Ross Gardler wrote:
>
>
>>>This remains uncomfortable, however. There appears to be no way to use
>>>XInclude without introducing a new DTD.
>>
>>That is correct. You can use a DTD that allows the xi:include stuff, or
>>we could add it to the XDoc DTD. I think the reason we never added it
>>was because we have always intended on moving the internal format over
>>to a subset of XHTML2, we would add it at this point.
>>
>>However, to date we have not done either.
>>
>>Patches to our DTDs are welcome.
>
>
> I have defined a DTD which allows me to use XInclude and validate:
>
> -------------------------------------------------------------------------
> <!ENTITY % local.inline "|xi:include">
> <!ENTITY % document PUBLIC
> "-//APACHE//ENTITIES Documentation V2.0//EN"
> "document-v20.dtd">
> %document;
>
> <!ATTLIST document
> xmlns:xi CDATA #FIXED "http://www.w3.org/2001/XInclude"
>
> <!ELEMENT xi:include EMPTY>
> <!ATTLIST xi:include
> parse (text|xml) "xml"
> href CDATA #REQUIRED
> encoding CDATA #IMPLIED
>
> -------------------------------------------------------------------------
>
> This works for my purposes. I enable XInclusion by using this doctype
> instead of document-v20.dtd.
>
> If this were to be done as a patch, I suppose the patch would introduce
> a new doctype V2.1, with the xi:include element moved into what would now
> be document-v21.mod. This would be added to catalog.xcat.
I don't think we need to create a version 2.1 for this to be honest. I
know we *should* but it is an optional element that is 100% backward
compatible.
Can we just slip it in without causing any upset? Naughty I know, but I
don't have the time to do a "proper job" on this.
>
> The exact place(s) where the xi:include element would be permitted might
> be an issue to some. I would add it to link-content.mix.
I agree.
Ross
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
(I'm moving this to the dev list, now we got past user issues)
Jim Dixon wrote:
> On Wed, 6 Sep 2006, Ross Gardler wrote:
>
>
>>>This remains uncomfortable, however. There appears to be no way to use
>>>XInclude without introducing a new DTD.
>>
>>That is correct. You can use a DTD that allows the xi:include stuff, or
>>we could add it to the XDoc DTD. I think the reason we never added it
>>was because we have always intended on moving the internal format over
>>to a subset of XHTML2, we would add it at this point.
>>
>>However, to date we have not done either.
>>
>>Patches to our DTDs are welcome.
>
>
> I have defined a DTD which allows me to use XInclude and validate:
>
> -------------------------------------------------------------------------
> <!ENTITY % local.inline "|xi:include">
> <!ENTITY % document PUBLIC
> "-//APACHE//ENTITIES Documentation V2.0//EN"
> "document-v20.dtd">
> %document;
>
> <!ATTLIST document
> xmlns:xi CDATA #FIXED "http://www.w3.org/2001/XInclude"
>
> <!ELEMENT xi:include EMPTY>
> <!ATTLIST xi:include
> parse (text|xml) "xml"
> href CDATA #REQUIRED
> encoding CDATA #IMPLIED
>
> -------------------------------------------------------------------------
>
> This works for my purposes. I enable XInclusion by using this doctype
> instead of document-v20.dtd.
>
> If this were to be done as a patch, I suppose the patch would introduce
> a new doctype V2.1, with the xi:include element moved into what would now
> be document-v21.mod. This would be added to catalog.xcat.
I don't think we need to create a version 2.1 for this to be honest. I
know we *should* but it is an optional element that is 100% backward
compatible.
Can we just slip it in without causing any upset? Naughty I know, but I
don't have the time to do a "proper job" on this.
>
> The exact place(s) where the xi:include element would be permitted might
> be an issue to some. I would add it to link-content.mix.
I agree.
Ross
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
On Wed, 6 Sep 2006, Ross Gardler wrote:
> > This remains uncomfortable, however. There appears to be no way to use
> > XInclude without introducing a new DTD.
>
> That is correct. You can use a DTD that allows the xi:include stuff, or
> we could add it to the XDoc DTD. I think the reason we never added it
> was because we have always intended on moving the internal format over
> to a subset of XHTML2, we would add it at this point.
>
> However, to date we have not done either.
>
> Patches to our DTDs are welcome.
I have defined a DTD which allows me to use XInclude and validate:
-------------------------------------------------------------------------
<!ENTITY % local.inline "|xi:include">
<!ENTITY % document PUBLIC
"-//APACHE//ENTITIES Documentation V2.0//EN"
"document-v20.dtd">
%document;
<!ATTLIST document
xmlns:xi CDATA #FIXED "http://www.w3.org/2001/XInclude"
>
<!ELEMENT xi:include EMPTY>
<!ATTLIST xi:include
parse (text|xml) "xml"
href CDATA #REQUIRED
encoding CDATA #IMPLIED
>
-------------------------------------------------------------------------
This works for my purposes. I enable XInclusion by using this doctype
instead of document-v20.dtd.
If this were to be done as a patch, I suppose the patch would introduce
a new doctype V2.1, with the xi:include element moved into what would now
be document-v21.mod. This would be added to catalog.xcat.
The exact place(s) where the xi:include element would be permitted might
be an issue to some. I would add it to link-content.mix.
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
Jim Dixon wrote:
> On Wed, 6 Sep 2006, Jim Dixon wrote:
>
>
>>Yes. If I set
>> forrest.validate.xdocs=false
>>in forrest.properties, then the 'forrest site' works.
>>
>>That is, this is indeed a simple workaround, for which I thank you.
>>
>>However, bear in mind that 'forrest run' did not fail. Also, 'forrest
>>validate-xdocs' returns
>> BUILD SUCCESSFUL
>>implying that there is an inconsistency in the way in which validation
>>is applied. For exactly the same configuration
>>
>> forrest run succeeds
>> forrest validate-xdocs succeeds
>> forrest site fails
>>
>>Looks like a bug to me.
>
>
> Correction: 'forrest validate-xdocs' fails only if forrest.validate.xdocs
> is set to false. If it is set to true, or just commented out, validation
> fails.
Yes, that is all correct. It's not a bug but a "feature". Validating
when doing a forrest run is irrelevant since we can edit the docs after
the initial ru and they could then be invalid.
> This remains uncomfortable, however. There appears to be no way to use
> XInclude without introducing a new DTD.
That is correct. You can use a DTD that allows the xi:include stuff, or
we could add it to the XDoc DTD. I think the reason we never added it
was because we have always intended on moving the internal format over
to a subset of XHTML2, we would add it at this point.
However, to date we have not done either.
Patches to our DTDs are welcome.
Ross
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
On Wed, 6 Sep 2006, Jim Dixon wrote:
> Yes. If I set
> forrest.validate.xdocs=false
> in forrest.properties, then the 'forrest site' works.
>
> That is, this is indeed a simple workaround, for which I thank you.
>
> However, bear in mind that 'forrest run' did not fail. Also, 'forrest
> validate-xdocs' returns
> BUILD SUCCESSFUL
> implying that there is an inconsistency in the way in which validation
> is applied. For exactly the same configuration
>
> forrest run succeeds
> forrest validate-xdocs succeeds
> forrest site fails
>
> Looks like a bug to me.
Correction: 'forrest validate-xdocs' fails only if forrest.validate.xdocs
is set to false. If it is set to true, or just commented out, validation
fails.
This remains uncomfortable, however. There appears to be no way to use
XInclude without introducing a new DTD.
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
On Wed, 6 Sep 2006, Thorsten Scherler wrote:
> > > > My only use of XInlude appears above. In logMeIn.xml I
> > > >
> > > > (a) add an xmlns:xi attribute to the document element
> > > > (b) add the xi:xinclude element
> > > >
> > > > Is either incorrect? Is there something else I should be doing?
> > >
> > > No that is fine. You also define the xinclude transformer in your
> > > sitemap, this is not necessary as it is defined in the root Forrest
> > > sitemap, but it will not be causing a problem.
> >
> > [Some readers will recall that there is no project sitemap.]
> >
> > Well, it doesn't cause a problem if you do a 'forrest run', but if
> > you do a 'forrest site', it fails:
> > ------------------------------------------------------------------------
> > validate-xdocs:
> > /home/j2ee/jappgen/src/documentation/content/xdocs/eg/logMeIn.xml:4:54:
> > Attribute "xmlns:xi" must be declared for element type "document".
> > /home/j2ee/jappgen/src/documentation/content/xdocs/eg/logMeIn.xml:13:73:
> > Element type "xi:include" must be declared.
> > /home/j2ee/jappgen/src/documentation/content/xdocs/eg/logMeIn.xml:13:82:
> > The content of element type "source" must match
> > "(strong|em|code|sub|sup|br|img|icon|acronym|map|a)".
> > ------------------------------------------------------------------------
> >
> > Now I'm hoping that there is a simple workaround that I am missing but ...
>
> Well it looks like the xinclude transformation got not executed before
> the validation. The quickest way would be to exclude the url for
> validation in the forrest.properties.
Yes. If I set
forrest.validate.xdocs=false
in forrest.properties, then the 'forrest site' works.
That is, this is indeed a simple workaround, for which I thank you.
However, bear in mind that 'forrest run' did not fail. Also, 'forrest
validate-xdocs' returns
BUILD SUCCESSFUL
implying that there is an inconsistency in the way in which validation
is applied. For exactly the same configuration
forrest run succeeds
forrest validate-xdocs succeeds
forrest site fails
Looks like a bug to me.
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Thorsten Scherler <th...@wyona.com>.
El mié, 06-09-2006 a las 15:00 +0100, Jim Dixon escribió:
> On Mon, 4 Sep 2006, Ross Gardler wrote:
>
> > > My only use of XInlude appears above. In logMeIn.xml I
> > >
> > > (a) add an xmlns:xi attribute to the document element
> > > (b) add the xi:xinclude element
> > >
> > > Is either incorrect? Is there something else I should be doing?
> >
> > No that is fine. You also define the xinclude transformer in your
> > sitemap, this is not necessary as it is defined in the root Forrest
> > sitemap, but it will not be causing a problem.
>
> [Some readers will recall that there is no project sitemap.]
>
> Well, it doesn't cause a problem if you do a 'forrest run', but if
> you do a 'forrest site', it fails:
> ------------------------------------------------------------------------
> validate-xdocs:
> /home/j2ee/jappgen/src/documentation/content/xdocs/eg/logMeIn.xml:4:54:
> Attribute "xmlns:xi" must be declared for element type "document".
> /home/j2ee/jappgen/src/documentation/content/xdocs/eg/logMeIn.xml:13:73:
> Element type "xi:include" must be declared.
> /home/j2ee/jappgen/src/documentation/content/xdocs/eg/logMeIn.xml:13:82:
> The content of element type "source" must match
> "(strong|em|code|sub|sup|br|img|icon|acronym|map|a)".
> ------------------------------------------------------------------------
>
> Now I'm hoping that there is a simple workaround that I am missing but ...
Well it looks like the xinclude transformation got not executed before
the validation. The quickest way would be to exclude the url for
validation in the forrest.properties.
salu2
>
> --
> Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
--
Thorsten Scherler
COO Spain
Wyona Inc. - Open Source Content Management - Apache Lenya
http://www.wyona.com http://lenya.apache.org
thorsten.scherler@wyona.com thorsten@apache.org
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
On Mon, 4 Sep 2006, Ross Gardler wrote:
> > My only use of XInlude appears above. In logMeIn.xml I
> >
> > (a) add an xmlns:xi attribute to the document element
> > (b) add the xi:xinclude element
> >
> > Is either incorrect? Is there something else I should be doing?
>
> No that is fine. You also define the xinclude transformer in your
> sitemap, this is not necessary as it is defined in the root Forrest
> sitemap, but it will not be causing a problem.
[Some readers will recall that there is no project sitemap.]
Well, it doesn't cause a problem if you do a 'forrest run', but if
you do a 'forrest site', it fails:
------------------------------------------------------------------------
validate-xdocs:
/home/j2ee/jappgen/src/documentation/content/xdocs/eg/logMeIn.xml:4:54:
Attribute "xmlns:xi" must be declared for element type "document".
/home/j2ee/jappgen/src/documentation/content/xdocs/eg/logMeIn.xml:13:73:
Element type "xi:include" must be declared.
/home/j2ee/jappgen/src/documentation/content/xdocs/eg/logMeIn.xml:13:82:
The content of element type "source" must match
"(strong|em|code|sub|sup|br|img|icon|acronym|map|a)".
------------------------------------------------------------------------
Now I'm hoping that there is a simple workaround that I am missing but ...
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
On Mon, 4 Sep 2006, Ross Gardler wrote:
> Ross Gardler wrote:
> > Jim Dixon wrote:
>
> ...
>
> > One thing I did not pick up on in your original post, but want to
> > clarify now is the line:
> >
> > "foo.txt is just a line of nonsense."
> >
> > Is it a line of *XML* nonsense? The XInclude transformer is an
> > implementation of the XINclude specification which is an XML
> > specification (see the Cocoon docs Thorsten pointed you at). It will
> > only work with XML source files.
>
> Ooops, no that is not correct, you are using the parse="text" attribute,
> you *can* include text with that.
Yes.
What I have sent so far is much simplified. I also tried XIncluding
XML files, with the same results: nothing appears. So I am trying to get
the simplest case working first.
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
Ross Gardler wrote:
> Jim Dixon wrote:
...
> One thing I did not pick up on in your original post, but want to
> clarify now is the line:
>
> "foo.txt is just a line of nonsense."
>
> Is it a line of *XML* nonsense? The XInclude transformer is an
> implementation of the XINclude specification which is an XML
> specification (see the Cocoon docs Thorsten pointed you at). It will
> only work with XML source files.
Ooops, no that is not correct, you are using the parse="text" attribute,
you *can* include text with that.
Ross
Re: xinclude
Posted by Sjur Moshagen <sj...@mac.com>.
Hello,
Sorry for spreading mis-information:
Den 4. sep. 2006 kl. 15.43 skrev Sjur Moshagen:
> Only drawback with using XIncludes (as opposed to CIncludes), is
> that there's no check on whether the included file has been
> changed, which means we need to touch the including file to get
> Forrest (run) to see changes in the included file.
This isn't true anymore, and probably hasn't been for a while.
Best,
Sjur
Re: xinclude
Posted by Sjur Moshagen <sj...@mac.com>.
Den 4. sep. 2006 kl. 15.30 skrev Jim Dixon:
> However! If I change the element to
>
> <xi:include parse="text" href="cocoon://eg/foo.txt"/>
>
> it works. I will be experimenting with this further, but it appears
> that the cocoon:// protocol is not just a Good Thing but mandatory.
Hm, it shouldn't be. We use XIncludes without the cocoon: protocoll,
and it works without problems. This is from our site.xml:
<xi:include href="doc/site-frag.xml#xpointer(/tech/*[@tab =
'how'])" />
We have seen no problems so far. Only drawback with using XIncludes
(as opposed to CIncludes), is that there's no check on whether the
included file has been changed, which means we need to touch the
including file to get Forrest (run) to see changes in the included file.
On the other hand, we get the full power of XPointers, which
CIncludes do not provide:-)
Best regards,
Sjur
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
On Mon, 4 Sep 2006, Ross Gardler wrote:
> > However! If I change the element to
> >
> > <xi:include parse="text" href="cocoon://eg/foo.txt"/>
> >
> > it works. I will be experimenting with this further, but it appears
> > that the cocoon:// protocol is not just a Good Thing but mandatory.
>
> It is not mandatory, you can use any protocol you like in the xinclude
> just as you can in any url anywhere in Forrest.
>
> If it works with the cocoon: protocol, but not with the relative path
> that you had previosuly then the actual location of your txt document
> was different from the relative path you define i your xinclude.
I just tried each of the following in turn:
<xi:include parse="text" href="foo.txt"/>
<xi:include parse="text" href="eg/foo.txt"/>
<xi:include parse="text" href="/eg/foo.txt"/>
<xi:include parse="text" href="cocoon://eg/foo.txt"/>
The first three fail as previously described. The last succeeds.
foo.txt is actually located in
src/documentation/content/xdocs/eg
I have not yet seen xi:include work for anything other than (a) a bare
file name preceded with the cocoon:// or (b) various types of indirect
reference like href="{.}" I suspect that these indirect references are
logically equivalent to the cocoon:// prefix. [But read on ...]
As regards
> It is not mandatory, you can use any protocol you like in the xinclude
> just as you can in any url anywhere in Forrest.
I experimented by adding
<xi:include parse="text" href="http://localhost/foo.txt"/>
To my surprise, this worked, as does
<xi:include parse="text" href="file:///var/www/docs/foo.txt"/>
This isn't exhaustive testing, but it appears that any protocol will do,
but just a bare file name won't. [Fiddles some more ...]
No, that's not right.
<xi:include parse="text" href="/var/www/docs/foo.txt"/>
works too.
So an absolute path will work. But I could not find any relative path
that would.
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
Jim Dixon wrote:
> On Mon, 4 Sep 2006, Ross Gardler wrote:
...
> However! If I change the element to
>
> <xi:include parse="text" href="cocoon://eg/foo.txt"/>
>
> it works. I will be experimenting with this further, but it appears
> that the cocoon:// protocol is not just a Good Thing but mandatory.
It is not mandatory, you can use any protocol you like in the xinclude
just as you can in any url anywhere in Forrest.
If it works with the cocoon: protocol, but not with the relative path
that you had previosuly then the actual location of your txt document
was different from the relative path you define i your xinclude.
Ross
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
On Mon, 4 Sep 2006, Ross Gardler wrote:
> If you add your XInclude stuff back in you get a resource not found error.
Not quite. There was a type in the xnlns:xi attribute:
<document xmlns:xi="http//www.w3.org/2001/XInclude">
If I get the page with this setup, the page appears on the screen, but
of course without the contents of foo.txt. If I put the colon in, I
get a "Resource Not Found" error.
> You say that the logs do not tell you exactly which file is missing
> (which is very unusual by the way, are you sure there is no file not
> found exception in the logs?)
Well, there are three identical ComponentLocator exceptions and
--------------------------------------------------------------------------
WARN (2006-09-04) 13:05.56:459 [access] (/eg/logMeIn.html) PoolThread-4/CocoonServlet: Resource not found.
at <map:serialize type="xml-document"> - file:/home/j2ee/forrest/main/webapp/forrest.xmap:230:47
at <map:transform> - file:/home/j2ee/forrest/main/webapp/forrest.xmap:128:65
at <map:generate> - file:/home/j2ee/forrest/main/webapp/forrest.xmap:226:42
at <map:serialize> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:326:23
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:324:73
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:318:72
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:296:42
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:571:65
at <map:transform type="linkrewriter"> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:570:79
at <map:transform type="xinclude"> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:569:41
at <map:transform type="idgen"> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:568:38
at <map:generate> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:567:49
at <map:serialize> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:326:23
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:324:73
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:318:72
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:296:42
--------------------------------------------------------------------------
> Since your original source is being found, it must be your included
> source that is not being found. You can confirm this by requesting
> eg/logMeIn.xml - you should see an XML document complete with your
> unprocessed XI:Include statements.
This works, returning the unprocessed
<xi:include parse="text" href="eg/foo.txt"/>
What may be significant is that the xlns:xi attribute has been stripped
from the <document> element. [Well, perhaps not. Read on.]
> So, check the location of your source document relative to your included
> document and verify that the path in the source document is the same.
They are.
> Note: it is better to use the cocoon:// protocol to resolve files since
> this will make your source files more portable.
Portability is a luxury to those of us whose simple, non-portable files
don't work. :-)
However! If I change the element to
<xi:include parse="text" href="cocoon://eg/foo.txt"/>
it works. I will be experimenting with this further, but it appears
that the cocoon:// protocol is not just a Good Thing but mandatory.
For the record, there are 4 uses of xi:include below forrest/plugins.
Three use the cocoon:// protocol and one uses href="{.}"
> [1]
> http://mail-archives.apache.org/mod_mbox/forrest-user/200609.mbox/browser
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
Jim Dixon wrote:
> On Mon, 4 Sep 2006, Ross Gardler wrote:
>
...
>
> Following earlier advice, I removed that and rely upon the main Forrest
> sitemap. In my first email today I wrote: "OK, this file, created after
> reading the advice above, has been dropped".
We are getting confused. I later asked you to add it back in (although
not explicitly I just said "XI:Include stuff"). However, now I know it
is not there lets leave it out (see below for the reason for the confusion).
You confirmed in an early post that if you remove the XInclude stuff
from your source document, the XML source file is found. Cool.
If you add your XInclude stuff back in you get a resource not found error.
You say that the logs do not tell you exactly which file is missing
(which is very unusual by the way, are you sure there is no file not
found exception in the logs?)
Since your original source is being found, it must be your included
source that is not being found. You can confirm this by requesting
eg/logMeIn.xml - you should see an XML document complete with your
unprocessed XI:Include statements.
So, check the location of your source document relative to your included
document and verify that the path in the source document is the same.
Note: it is better to use the cocoon:// protocol to resolve files since
this will make your source files more portable.
As I have said earlier in the post, there are examples of how to do all
this in the plugins directory.
>>This should be the pipeline that does the work in your project as
>>project sitemaps override the Forrest sitemaps.
>
>
> Is there a reason for using a project sitemap rather than relying on
> the main one?
Yes, and no.
XInclude is not enabled in all pipelines by default. It would create an
unnecessary processing step in the vast majority of cases. For example,
it is not enabled in the XML pipelines, but it is enabled in the html
pipelines. Therefore if you are XIncluding HTML you do not need to
override your sitemap, but if you want to add XML you do need to, I
assumed that you needed to do this as you had done so in your first
example.
Lets leave it out for now.
Ross
[1]
http://mail-archives.apache.org/mod_mbox/forrest-user/200609.mbox/browser
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
On Mon, 4 Sep 2006, Ross Gardler wrote:
> > Message: Resource Not Found
> > Description: The requested resource "/eg/logMeIn.html" could not be found.
> > Sender: org.apache.cocoon.servlet.CocoonServlet
> > Source: Cocoon Servlet
> >
> > and the logs contain
> > ---------------------------------------------------------------------------
> > WARN (2006-09-04) 10:15.19:459 [access] (/eg/logMeIn.html) PoolThread-4/CocoonServlet: Resource not found.
> > at <map:serialize type="xml-document"> - file:/home/j2ee/forrest/main/webapp/forrest.xmap:230:47
> > at <map:transform> - file:/home/j2ee/forrest/main/webapp/forrest.xmap:128:65
> > at <map:generate> - file:/home/j2ee/forrest/main/webapp/forrest.xmap:226:42
> > at <map:serialize> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:326:23
> > at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:324:73
> > at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:318:72
> > at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:296:42
> > at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:571:65
> > at <map:transform type="linkrewriter"> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:570:79
> > at <map:transform type="xinclude"> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:569:41
> > at <map:transform type="idgen"> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:568:38
> > at <map:generate> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:567:49
> > at <map:serialize> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:326:23
> > at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:324:73
> > at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:318:72
> > at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:296:42
> > ---------------------------------------------------------------------------
> > Yes, this is a warning, but it does appear to be quite relevant.
> >
>
> ...
>
> >
> > The error occurs at line 230 in main/forrest.xmap, which is the
> > serialization stage in i18n of XML files.
>
> This pipeline should not be processed since you have a project sitemap with:
>
> <map:match pattern="eg/logMeIn.xml">
> <map:generate src="eg/logMeIn.xml"/>
> <map:transform type="xinclude"/>
> <map:serialize type="xml"/>
> </map:match>
Following earlier advice, I removed that and rely upon the main Forrest
sitemap. In my first email today I wrote: "OK, this file, created after
reading the advice above, has been dropped".
> This should be the pipeline that does the work in your project as
> project sitemaps override the Forrest sitemaps.
Is there a reason for using a project sitemap rather than relying on
the main one?
This appears to be a red herring. If the main sitemap is handling this
correctly, it seems pointless to introduce a project sitemap with
exactly the same functionality. If the main sitemap is not handling
XIncludes correctly, then we have a bug.
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
Jim Dixon wrote:
> On Mon, 4 Sep 2006, Ross Gardler wrote:
>
...
>
>
> Message: Resource Not Found
> Description: The requested resource "/eg/logMeIn.html" could not be found.
> Sender: org.apache.cocoon.servlet.CocoonServlet
> Source: Cocoon Servlet
>
> and the logs contain
> ---------------------------------------------------------------------------
> WARN (2006-09-04) 10:15.19:459 [access] (/eg/logMeIn.html) PoolThread-4/CocoonServlet: Resource not found.
> at <map:serialize type="xml-document"> - file:/home/j2ee/forrest/main/webapp/forrest.xmap:230:47
> at <map:transform> - file:/home/j2ee/forrest/main/webapp/forrest.xmap:128:65
> at <map:generate> - file:/home/j2ee/forrest/main/webapp/forrest.xmap:226:42
> at <map:serialize> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:326:23
> at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:324:73
> at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:318:72
> at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:296:42
> at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:571:65
> at <map:transform type="linkrewriter"> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:570:79
> at <map:transform type="xinclude"> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:569:41
> at <map:transform type="idgen"> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:568:38
> at <map:generate> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:567:49
> at <map:serialize> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:326:23
> at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:324:73
> at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:318:72
> at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:296:42
> ---------------------------------------------------------------------------
> Yes, this is a warning, but it does appear to be quite relevant.
>
...
>
> The error occurs at line 230 in main/forrest.xmap, which is the
> serialization stage in i18n of XML files.
This pipeline should not be processed since you have a project sitemap with:
<map:match pattern="eg/logMeIn.xml">
<map:generate src="eg/logMeIn.xml"/>
<map:transform type="xinclude"/>
<map:serialize type="xml"/>
</map:match>
This should be the pipeline that does the work in your project as
project sitemaps override the Forrest sitemaps.
It looks to me like your sitempap is not being processed. This would
result in a resource not found error because you are storing your source
files in a non-standard location (at least according to the above
sitemap snippet you are).
Where have you put your project sitemap?
You can confirm your project sitemap is not being used by deliberately
creating an error in the XML (e.g. drop a closing bracket). You should
get an error telling you it is invalid XML, if you don't then Forrest is
not looking at your sitemap.
Ross
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
On Mon, 4 Sep 2006, Ross Gardler wrote:
> > The question is not whether XInclude works in Forrest. It's a simple
> > how-to: how do you XInclude a text file in a Forrest document?
>
> I appreciate that, but you already have the "how-to" from Thorstens
> previous responses and the existing Forrest code (do a search for
> xi:include in the plugins directory, you will find it in use. For now,
> read on...
Searching forrest/plugins with
grep -e "xi:include" -rl * | grep -v svn
I found two files in which XInclude is used.
> >>If it does work then it is something to do with your use of Xinclude,
> >
> > My only use of XInlude appears above. In logMeIn.xml I
> >
> > (a) add an xmlns:xi attribute to the document element
> > (b) add the xi:xinclude element
> >
> > Is either incorrect? Is there something else I should be doing?
>
> No that is fine. You also define the xinclude transformer in your
> sitemap, this is not necessary as it is defined in the root Forrest
> sitemap, but it will not be causing a problem.
There was actually an error here:
<document xmlns:xi="http//www.w3.org/2001/XInclude">
The colon after "http" was omitted.
If the colon is inserted, then we once again get
Message: Resource Not Found
Description: The requested resource "/eg/logMeIn.html" could not be found.
Sender: org.apache.cocoon.servlet.CocoonServlet
Source: Cocoon Servlet
and the logs contain
---------------------------------------------------------------------------
WARN (2006-09-04) 10:15.19:459 [access] (/eg/logMeIn.html) PoolThread-4/CocoonServlet: Resource not found.
at <map:serialize type="xml-document"> - file:/home/j2ee/forrest/main/webapp/forrest.xmap:230:47
at <map:transform> - file:/home/j2ee/forrest/main/webapp/forrest.xmap:128:65
at <map:generate> - file:/home/j2ee/forrest/main/webapp/forrest.xmap:226:42
at <map:serialize> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:326:23
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:324:73
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:318:72
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:296:42
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:571:65
at <map:transform type="linkrewriter"> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:570:79
at <map:transform type="xinclude"> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:569:41
at <map:transform type="idgen"> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:568:38
at <map:generate> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:567:49
at <map:serialize> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:326:23
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:324:73
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:318:72
at <map:transform> - file:/home/j2ee/forrest/main/webapp/sitemap.xmap:296:42
---------------------------------------------------------------------------
Yes, this is a warning, but it does appear to be quite relevant.
If I reintroduce the error (delete the colon), then the error message goes
away.
The error occurs at line 230 in main/forrest.xmap, which is the
serialization stage in i18n of XML files. It looks to me like the
preceding transform-to-document stage is producing the wrong type of
content.
> One thing I did not pick up on in your original post, but want to
> clarify now is the line:
>
> "foo.txt is just a line of nonsense."
>
> Is it a line of *XML* nonsense? The XInclude transformer is an
> implementation of the XINclude specification which is an XML
> specification (see the Cocoon docs Thorsten pointed you at). It will
> only work with XML source files.
;-)
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
Jim Dixon wrote:
> On Sun, 3 Sep 2006, Ross Gardler wrote:
>
>
>>Jim Dixon wrote:
>>
>>>On Thu, 29 Jun 2006, Thorsten Scherler wrote:
>>>
>>>>Have a look at
>>>>http://cocoon.apache.org/2.1/userdocs/xinclude-transformer.html
>>>>and add xmlns:xi="http://www.w3.org/2001/XInclude" to the document tag
>>>>like:
>>>><document xmlns:xi="http://www.w3.org/2001/XInclude">
>>>
...
>>XInclude works fine in Forrest, it is used internally in a few places.
>
>
> The question is not whether XInclude works in Forrest. It's a simple
> how-to: how do you XInclude a text file in a Forrest document?
I appreciate that, but you already have the "how-to" from Thorstens
previous responses and the existing Forrest code (do a search for
xi:include in the plugins directory, you will find it in use. For now,
read on...
>>Try commenting out the xi:include element in your source and remove your
>> project sitemap. Does it work?
>
>
> If the project sitemap is removed, then the page appears, but without
> any XIncluded text.
That is as expected and serves to confirm that the problem is either in
the Include processing or in your project sitemap. But we do not know
which yet. Lets read on...
>>If it does work then it is something to do with your use of Xinclude,
>
>
> My only use of XInlude appears above. In logMeIn.xml I
>
> (a) add an xmlns:xi attribute to the document element
> (b) add the xi:xinclude element
>
> Is either incorrect? Is there something else I should be doing?
No that is fine. You also define the xinclude transformer in your
sitemap, this is not necessary as it is defined in the root Forrest
sitemap, but it will not be causing a problem.
>>you should find more information in the logs (see our FAQ if you don't
>>know where they are). If they don't help you paste anything you think
>>may be useful here.
>>
>>Ross
>
>
> FWIW I used svn to get the very latest version of Forrest a few minutes
> ago, did a 'forrest run', and then used my browser to look at logMeIn.xml.
> The log then contains three identical entries:
>
> -------------------------------------------------------------------------
> WARN (2006-09-04) 08:11.53:847 [core.manager] (/eg/logMeIn.html) PoolThread-4/CoreServiceManager: ComponentLocator exception from parent SM during lookup.
> org.apache.avalon.framework.service.ServiceException: Component for key 'org.apache.cocoon.components.treeprocessor.TreeBuilder/sitemap-1.0' not found. (Key='Cocoon')
These are not a problem, note they are "WARN"ings (first entry in the
line), they are not errors.
You now need to turn your xinclude stuff back on and find the errors
that are reported in the logs, this will tell us what the problem is.
One thing I did not pick up on in your original post, but want to
clarify now is the line:
"foo.txt is just a line of nonsense."
Is it a line of *XML* nonsense? The XInclude transformer is an
implementation of the XINclude specification which is an XML
specification (see the Cocoon docs Thorsten pointed you at). It will
only work with XML source files.
Ross
Re: xinclude
Posted by Jim Dixon <jd...@dixons.org>.
On Sun, 3 Sep 2006, Ross Gardler wrote:
> Jim Dixon wrote:
> > On Thu, 29 Jun 2006, Thorsten Scherler wrote:
> >>Have a look at
> >>http://cocoon.apache.org/2.1/userdocs/xinclude-transformer.html
> >>and add xmlns:xi="http://www.w3.org/2001/XInclude" to the document tag
> >>like:
> >><document xmlns:xi="http://www.w3.org/2001/XInclude">
> >
> > Has anyone been able to get this working with Forrest? I have followed
> > their instructions closely but it appears that the transformed file
> > doesn't get passed on.
OK, this file, created after reading the advice above, has been
dropped:
> > -- sitemap.xmap ---------------------------------------------------------
> > <?xml version="1.0"?>
> > <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
> > <map:components>
> > <map:transformers default="xslt">
> > <map:transformer name="xinclude"
> > src="org.apache.cocoon.transformation.XIncludeTransformer"/>
> > </map:transformers>
> > </map:components>
> > <map:pipelines>
> > <map:pipeline>
> > <map:match pattern="eg/logMeIn.xml">
> > <map:generate src="eg/logMeIn.xml"/>
> > <map:transform type="xinclude"/>
> > <map:serialize type="xml"/>
> > </map:match>
> > </map:pipeline>
> > </map:pipelines>
> > </map:sitemap>
This file remains:
> > -- logMeIn.xml ----------------------------------------------------------
> > <?xml version="1.0" encoding="UTF-8"?>
> > <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
> > <document xmlns:xi="http//www.w3.org/2001/XInclude">
> > <header><title>logMeIn</title></header>
> > <body>
> > <source>
> > <xi:include parse="text" href="eg/foo.txt"/>
> > </source>
> > </body>
> > </document>
> > -------------------------------------------------------------------------
> > foo.txt is just a line of nonsense.
> XInclude works fine in Forrest, it is used internally in a few places.
The question is not whether XInclude works in Forrest. It's a simple
how-to: how do you XInclude a text file in a Forrest document?
> Try commenting out the xi:include element in your source and remove your
> project sitemap. Does it work?
If the project sitemap is removed, then the page appears, but without
any XIncluded text.
> If it does work then it is something to do with your use of Xinclude,
My only use of XInlude appears above. In logMeIn.xml I
(a) add an xmlns:xi attribute to the document element
(b) add the xi:xinclude element
Is either incorrect? Is there something else I should be doing?
> you should find more information in the logs (see our FAQ if you don't
> know where they are). If they don't help you paste anything you think
> may be useful here.
>
> Ross
FWIW I used svn to get the very latest version of Forrest a few minutes
ago, did a 'forrest run', and then used my browser to look at logMeIn.xml.
The log then contains three identical entries:
-------------------------------------------------------------------------
WARN (2006-09-04) 08:11.53:847 [core.manager] (/eg/logMeIn.html) PoolThread-4/CoreServiceManager: ComponentLocator exception from parent SM during lookup.
org.apache.avalon.framework.service.ServiceException: Component for key 'org.apache.cocoon.components.treeprocessor.TreeBuilder/sitemap-1.0' not found. (Key='Cocoon')
at org.apache.cocoon.core.container.SingleComponentServiceManager.lookup(SingleComponentServiceManager.java:68)
at org.apache.cocoon.core.container.CoreServiceManager.lookup(CoreServiceManager.java:355)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.getTreeBuilder(TreeProcessor.java:375)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.buildConcreteProcessor(TreeProcessor.java:720)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.setupConcreteProcessor(TreeProcessor.java:394)
at org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:288)
at org.apache.cocoon.Cocoon.process(Cocoon.java:557)
at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:364)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:354)
at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1808)
at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1758)
at org.mortbay.http.HttpServer.service(HttpServer.java:879)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:790)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:952)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:807)
at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:197)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:501)
-------------------------------------------------------------------------
--
Jim Dixon jdd@dixons.org tel +44 117 982 0786 mobile +44 797 373 7881
Re: xinclude
Posted by Ross Gardler <rg...@apache.org>.
Jim Dixon wrote:
> On Thu, 29 Jun 2006, Thorsten Scherler wrote:
>
>
>>Have a look at
>>http://cocoon.apache.org/2.1/userdocs/xinclude-transformer.html
>>and add xmlns:xi="http://www.w3.org/2001/XInclude" to the document tag
>>like:
>><document xmlns:xi="http://www.w3.org/2001/XInclude">
>
>
> Has anyone been able to get this working with Forrest? I have followed
> their instructions closely but it appears that the transformed file
> doesn't get passed on.
>
> -- sitemap.xmap ---------------------------------------------------------
> <?xml version="1.0"?>
> <map:sitemap xmlns:map="http://apache.org/cocoon/sitemap/1.0">
> <map:components>
> <map:transformers default="xslt">
> <map:transformer name="xinclude"
> src="org.apache.cocoon.transformation.XIncludeTransformer"/>
> </map:transformers>
> </map:components>
> <map:pipelines>
> <map:pipeline>
> <map:match pattern="eg/logMeIn.xml">
> <map:generate src="eg/logMeIn.xml"/>
> <map:transform type="xinclude"/>
> <map:serialize type="xml"/>
> </map:match>
> </map:pipeline>
> </map:pipelines>
> </map:sitemap>
>
> -- logMeIn.xml ----------------------------------------------------------
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE document PUBLIC "-//APACHE//DTD Documentation V2.0//EN" "http://forrest.apache.org/dtd/document-v20.dtd">
> <document xmlns:xi="http//www.w3.org/2001/XInclude">
> <header><title>logMeIn</title></header>
> <body>
> <source>
> <xi:include parse="text" href="eg/foo.txt"/>
> </source>
> </body>
> </document>
> -------------------------------------------------------------------------
> foo.txt is just a line of nonsense.
>
> Cocoon returns:
> -------------------------------------------------------------------------
> Message: Resource Not Found
> Description: The requested resource "/eg/logMeIn.html" could not be found
> Sender: org.apache.cocoon.servlet.CocoonServlet
> Source: Cocoon Servlet
> -------------------------------------------------------------------------
XInclude works fine in Forrest, it is used internally in a few places.
Try commenting out the xi:include element in your source and remove your
project sitemap. Does it work?
If it doesn't then your source logMeIn.xml file is not where Forrest
expects to find them. Check your paths.
If it does work then it is something to do with your use of Xinclude,
you should find more information in the logs (see our FAQ if you don't
know where they are). If they don't help you paste anything you think
may be useful here.
Ross