You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Upayavira <uv...@upaya.co.uk> on 2003/09/01 16:21:20 UTC
Re: Finding DTD when aggregating content using XSL (resolved
The following is my understanding:
The use of document() in Cocoon is not recommended because it is
difficult for Cocoon to 'intercept' these functions. Elsewhere, Cocoon
can use its own source mechanisms to handle things like caching, entity
resolving, referencing the cocoon protocol, etc. However, XSLT
transformers will bypass Cocoon's mechanisms and go direct to the system
to resolve resources when using document(). Thus, a broken Cocoon
caching system, no entity resolving, no cocoon: protocol, etc, etc.
That is why you are better recommended to use <map:aggregate> or the
cinclude/xinclude transformers to pull multiple documents into one
before doing an XSLT on them.
Regards, Upayavira
Albert Bruffaerts wrote:
> Hello.
>
>
> I just wanted to know whether the behaviour described in the email
> thread started on Fri, 09 Aug 2002 12:55:24 -0700 by Ross Gardler has
> generated some follow-up, or even better some correcting patch.
>
>
> Indeed, today in Sep 2003, I am still observing exactly the same
> behaviour:
>
> a. XML parsers used by XSLT transformers activated directly from a
> sitemap pipelines are using the Cocoon entity catalogs to get access
> to DTD files
>
> b. XML parsers used to perform execution of calls to XSLT function
> "document()" embedded in XSLT scripts used by XSLT transformers
> activated directly from a sitemap pipelines are not using the Cocoon
> entity catalogs to get access to DTD files
>
> I am using:
> Cocoon 2.1
> Tomcat 4.1.24
> JDK 1.4
> Xerces 2.4.0
> Xalan 2.5.1
>
>
> Even if from the Cocoon XSLT FAQs, I read that the use of document()
> is not recommended within the Cocoon context (What's "wrong" with the
> use of the document() function in Cocoon), I consider it rather
> surprising that the Cocoon entity catalogs seem not to be used by all
> XML parsers instantiated within the Cocoon context.
>
>
> Please, could you tell me whether I miss a step somewhere
> or whether this behaviour is the symptom of a bug in the wiring of
> Cocoon components (specifically some XML parser instances)?
>
>
> Thank you very much for your cooperation.
>
>
> Best regards,
> Albert Bruffaerts
>
>
> -----------------------------------------------------------------
> Sema Belgium SA http://be.sema.com
> rue de Stalle 96 mailto:albert.bruffaerts@brussels.sema.slb.com
> B-1180 Brussels fax: +32 2 333 55 22
> Belgium tel: +32 2 333 52 34 / 58 (secr.)
> -----------------------------------------------------------------
> Member of SchlumbergerSema, a segment of Schlumberger Ltd.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Finding DTD when aggregating content using XSL (resolved
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Upayavira wrote:
> The use of document() in Cocoon is not recommended because it is
> difficult for Cocoon to 'intercept' these functions.
Cocoon successfully intercepts document() calls and redirects them
to a Cocoon source, using the JAXP URIResolver mechanism. This means
ocoon catalog resolving and even cocoon: scheme URLs work (I tried
the latter). The problems with this were, at least in 2.0.5:
- Document() sources weren't accounted for caching of the pipeline
result, which means you get old results even if content pulled
via document() changed.
- Using Saxon as XSLT processor tended to result in NPEs, perhaps
because of some intereference between the EntityResolver and the
URL resolver, resulting in early disposal of the Cocoon source.
There were discussions about fixing the first problem in 2.1, I
havn't tested it though.
> However, XSLT
> transformers will bypass Cocoon's mechanisms and go direct to the system
> to resolve resources when using document().
Ah, not quite.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org