You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by "Horsfield, Peter A." <pe...@ngc.com> on 2003/10/17 00:30:17 UTC
Crusading for the XSLT document() function
document('cocoon:/myinternalpipeline');
SoC... Caching... Virtual URI space... Pipeline reuse...
All it would take is for Cocoon to keep an eye out for calls to the
SourceResolver, and perhaps for request parameters to be
passed smartly. Better yet, force all document('...') requests be
Cocoon internal protocol requests.
Counter points:
Source Pure XML -
You get one pure XML source indirectly
AND you get to use all the existing XML
application specific tools for your other source.
Aggregation -
Aggregation is not the force for SoC it is presented as.
It is good only for simple single level cases. As soon
as you aggregate aggregations, you've lost the case.
Speed -
In an attempt to speed up processing, I removed the
document function, and cincluded the data
into the source. It made no difference. (Solaris 8 -
there were other speed issues at the time).
DOM / SAX -
Aggregation pumps entire blocks of SAX events. This is
fine, XSLT may be worse. But XSLT (or STX) implementations
do have the freedom to optimize this stuff. The semantics of
aggregation do not allow this freedom.
Now if the developers of Cocoon think that using the document function is
not a good use of Cocoon, then so be it. I think that in conjunction with
the Cocoon protocol, it is a powerful feature that supports SoC.
When it comes down to it aggregation and the document function do fulfil
the same need. The only reason I would pick the XSLT document function
over aggregation, is... it just feels right.
After writing this all down, I think I've decided that both aggregation and
document() suck in Cocoon. There has got to be a better way.
Cocoon 3, perhaps.
Regards,
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Crusading for the XSLT document() function
Posted by Robert Koberg <ro...@koberg.com>.
Hi,
> -----Original Message-----
> From: J.Pietschmann [mailto:j3322ptm@yahoo.de]
> Sent: Monday, October 20, 2003 1:29 PM
> To: users@cocoon.apache.org
>
> Lars Huttar wrote:
> > I am using regular xalan. I haven't tried the others, though
> > I've considered switching to Saxon since there are some other
> > cases where it seems to do better (specifically, in reporting
> > errors).
>
> Unfortunately, Saxon tended to produce NPEs with document()
> in C2.0.4 and an earlier 2.1dev, even after the Source NPE
> fixes. It had something to do with the SourceResolver disposed
> early, I think. I didn't check whether this is fixed now.
When I did some testing of the most popular java OS processors (xalan, saxon
& jd.xslt), one difference in favor (?) of xalan happened when resolving
Sources. Saxon requires that a system ID is set for a generated Source,
while xalan accepted a generated Source without setting (or having) a system
ID.
-Rob
>
> J.Pietschmann
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Crusading for the XSLT document() function
Posted by "J.Pietschmann" <j3...@yahoo.de>.
Lars Huttar wrote:
> I am using regular xalan. I haven't tried the others, though
> I've considered switching to Saxon since there are some other
> cases where it seems to do better (specifically, in reporting
> errors).
Unfortunately, Saxon tended to produce NPEs with document()
in C2.0.4 and an earlier 2.1dev, even after the Source NPE
fixes. It had something to do with the SourceResolver disposed
early, I think. I didn't check whether this is fixed now.
J.Pietschmann
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Crusading for the XSLT document() function
Posted by Lars Huttar <la...@sil.org>.
Hello Rob,
Thanks for your helpful suggestions.
Actually, I feel dumb, but ... I can't reproduce the bug anymore.
:-S
So I guess for the time being I'll leave things as they are,
since whatever changes I might make, I wouldn't be able to tell
whether they were helping.
> Are you using XSLTC? Have you tried the regular xalan or
> saxon?
I am using regular xalan. I haven't tried the others, though
I've considered switching to Saxon since there are some other
cases where it seems to do better (specifically, in reporting
errors).
> I remember
> reading recently on xalan-dev about a bug in relative path
> resolution in
> xsltc.
Sounds like that may well be it (as I suspected originally).
> Also xsltc and regular xalan use two different ways of assigning the
> URIResolver. Perhaps cocoon is geared toward one or the
> other. Saxon has the
> best solution (it uses both ways) so it might be the best
> choice. I have
> posted some info on both commons-dev and xalan dev about the
> issue that
> should be in the archives but if you want further info, let me know.
Thanks; actually for now I feel like I've spent too much time on
this and it's working for me now, so I'll just leave it unless
it bites me again.
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Crusading for the XSLT document() function
Posted by Robert Koberg <ro...@koberg.com>.
Hi Lars,
Are you using XSLTC? Have you tried the regular xalan or saxon? I remember
reading recently on xalan-dev about a bug in relative path resolution in
xsltc.
Also xsltc and regular xalan use two different ways of assigning the
URIResolver. Perhaps cocoon is geared toward one or the other. Saxon has the
best solution (it uses both ways) so it might be the best choice. I have
posted some info on both commons-dev and xalan dev about the issue that
should be in the archives but if you want further info, let me know.
Best,
-Rob
> -----Original Message-----
> From: Lars Huttar [mailto:lars_huttar@sil.org]
> Sent: Monday, October 20, 2003 7:29 AM
> To: users@cocoon.apache.org
>
> > From: Bruno Dumon
> ...
> > However, in your case you don't need caching, which you can
> > easily work
> > around with by putting the pipeline inside a <map:pipeline> with an
> > attribute type="noncaching".
>
> Thanks, I will try that.
>
> > > OK.
> > > I guess I should submit a bug report to bugzilla. (That's
> > all I can do.)
> >
> > there is/was already one, but it was then closed an moved as a feature
> > request to a wiki page:
> > http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatureRequests
>
> I saw this one, which says
>
> # Modify the caching system so that it is possible to:
>
> * include docs referenced by XSLT's document() in the cache validity
> (bugzilla 10203)
>
> But I don't think that covers the problem I'm referring to...
> please correct me if I'm wrong.
> This "feature request" sounds like it's asking for Cocoon to keep
> track of whether the document accessed by document() from a stylesheet
> has been modified; the only problem this feature is intended to solve,
> if I understand it, is that a certain request might return old data
> when the referenced document has been changed.
>
> The problem I'm referring to is one where document() doesn't find
> the requested document in the first place, due to faulty URI-resolution.
>
> Anyway I submitted bug report 23939 before I saw your latest email.
> I hope it can be distinguished from the above feature request.
>
> Lars
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Crusading for the XSLT document() function
Posted by Lars Huttar <la...@sil.org>.
> From: Bruno Dumon
...
> However, in your case you don't need caching, which you can
> easily work
> around with by putting the pipeline inside a <map:pipeline> with an
> attribute type="noncaching".
Thanks, I will try that.
> > OK.
> > I guess I should submit a bug report to bugzilla. (That's
> all I can do.)
>
> there is/was already one, but it was then closed an moved as a feature
> request to a wiki page:
> http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatureRequests
I saw this one, which says
# Modify the caching system so that it is possible to:
* include docs referenced by XSLT's document() in the cache validity (bugzilla 10203)
But I don't think that covers the problem I'm referring to...
please correct me if I'm wrong.
This "feature request" sounds like it's asking for Cocoon to keep
track of whether the document accessed by document() from a stylesheet
has been modified; the only problem this feature is intended to solve,
if I understand it, is that a certain request might return old data
when the referenced document has been changed.
The problem I'm referring to is one where document() doesn't find
the requested document in the first place, due to faulty URI-resolution.
Anyway I submitted bug report 23939 before I saw your latest email.
I hope it can be distinguished from the above feature request.
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Crusading for the XSLT document() function
Posted by Bruno Dumon <br...@outerthought.org>.
On Mon, 2003-10-20 at 15:49, Lars Huttar wrote:
<snip/>
> E.g. the response to my report of an apparent bug
> in Cocoon's handling of a document() URI, in the
> "problem with relative URI in document() in XSLT in Cocoon" thread:
>
> > You shouldn't use document() in Cocoon style sheets anyway, for a
> > variety of reasons, one of them bein problems with caching.
> > Use <map:aggregate>, XInclude or CInclude instead.
>
> When I explained that this was a case where caching was not a problem,
> and asked for any other reason why I should avoid document() (or,
> I should add, why I shouldn't expect document() to work according
> to the XSLT spec), there has been no further response.
> I can understand why one poster felt that minds are closed on
> this issue. Obviously not all minds, but...
>
Caching with transformers that perform some kind of inclusion is
currently a problem in Cocoon, but so far it hasn't annoyed anyone
enough to solve the issue (though there's been lots of complaints from
users). Note that the XIncludeTransformer also isn't cacheable, and
while the CIncludeTransformer does some sort of caching it's not really
like one would expect (namely that the cache becomes invalid when one of
the included sources changed). Solving this would require some changes
to Cocoon's caching system.
However, in your case you don't need caching, which you can easily work
around with by putting the pipeline inside a <map:pipeline> with an
attribute type="noncaching".
>
> > Whether one likes it or not, we have seen huge performance gains by
> > minimizing the number of XSLT transformations in a pipeline,
> > even at the
> > end of building one-off custom SAXTransformers to replace some XSLT
> > stylesheets.
>
> Cool.
>
> > Cocoon is XML-centric, and might be a nice
> > environment to
> > do server-side XSLT transformations, but I find it difficult to state
> > that XSLT (and the document() function) is the panacea for all webapp
> > development related problems, or more specific aggregation,
> > or whatelse.
>
> Agreed, document() isn't the best tool for all cases.
>
> My understanding is that this "crusade" was not to spread the
> use of document() to all cases, but to rescue it from being
> bluntly disparaged even in the cases where it's useful,
fwiw, that was also my understanding of it, and I agree with it.
> and
> from being poorly supported.
>
> That's my point anyway, i.e., if Cocoon is XML-centric and
> uses XSLT a lot, it would seem pretty important that document() is
> handled correctly even if there are cases where it shouldn't be used.
>
> > That being said, if anything is missing w.r.t. document() / Source /
> > caching support in Cocoon (or Xalan!), I'm pretty sure
> > patches will be accepted gratefully.
>
> OK.
> I guess I should submit a bug report to bugzilla. (That's all I can do.)
there is/was already one, but it was then closed an moved as a feature
request to a wiki page:
http://wiki.cocoondev.org/Wiki.jsp?page=CocoonFeatureRequests
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Crusading for the XSLT document() function
Posted by Lars Huttar <la...@sil.org>.
Steven Noels wrote:
> Lars Huttar wrote:
>
> > I think Peter's email that started this thread was not saying
> > that only document() should be used, but rather asking,
> > why exclude document()?
>
> There's a big difference between 'excluding', and 'not
> recommending for
> specific usecases'. AFAIK, nobody 'excluded' the use of document() in
> Cocoon. I think some are just trying to warn people that one
> should be
> aware of the side-effects caused by the use of this function.
That's where our point of view differs. My impression is that
some are opposing the use and support of document() (in Cocoon)
in general without considering the cases where it would be useful.
E.g. the response to my report of an apparent bug
in Cocoon's handling of a document() URI, in the
"problem with relative URI in document() in XSLT in Cocoon" thread:
> You shouldn't use document() in Cocoon style sheets anyway, for a
> variety of reasons, one of them bein problems with caching.
> Use <map:aggregate>, XInclude or CInclude instead.
When I explained that this was a case where caching was not a problem,
and asked for any other reason why I should avoid document() (or,
I should add, why I shouldn't expect document() to work according
to the XSLT spec), there has been no further response.
I can understand why one poster felt that minds are closed on
this issue. Obviously not all minds, but...
> Whether one likes it or not, we have seen huge performance gains by
> minimizing the number of XSLT transformations in a pipeline,
> even at the
> end of building one-off custom SAXTransformers to replace some XSLT
> stylesheets.
Cool.
> Cocoon is XML-centric, and might be a nice
> environment to
> do server-side XSLT transformations, but I find it difficult to state
> that XSLT (and the document() function) is the panacea for all webapp
> development related problems, or more specific aggregation,
> or whatelse.
Agreed, document() isn't the best tool for all cases.
My understanding is that this "crusade" was not to spread the
use of document() to all cases, but to rescue it from being
bluntly disparaged even in the cases where it's useful, and
from being poorly supported.
That's my point anyway, i.e., if Cocoon is XML-centric and
uses XSLT a lot, it would seem pretty important that document() is
handled correctly even if there are cases where it shouldn't be used.
> That being said, if anything is missing w.r.t. document() / Source /
> caching support in Cocoon (or Xalan!), I'm pretty sure
> patches will be accepted gratefully.
OK.
I guess I should submit a bug report to bugzilla. (That's all I can do.)
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Crusading for the XSLT document() function
Posted by Steven Noels <st...@outerthought.org>.
Lars Huttar wrote:
> I think Peter's email that started this thread was not saying
> that only document() should be used, but rather asking,
> why exclude document()?
There's a big difference between 'excluding', and 'not recommending for
specific usecases'. AFAIK, nobody 'excluded' the use of document() in
Cocoon. I think some are just trying to warn people that one should be
aware of the side-effects caused by the use of this function.
Whether one likes it or not, we have seen huge performance gains by
minimizing the number of XSLT transformations in a pipeline, even at the
end of building one-off custom SAXTransformers to replace some XSLT
stylesheets. Cocoon is XML-centric, and might be a nice environment to
do server-side XSLT transformations, but I find it difficult to state
that XSLT (and the document() function) is the panacea for all webapp
development related problems, or more specific aggregation, or whatelse.
That being said, if anything is missing w.r.t. document() / Source /
caching support in Cocoon (or Xalan!), I'm pretty sure patches will be
accepted gratefully.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Crusading for the XSLT document() function
Posted by Lars Huttar <la...@sil.org>.
> 1) it hides away the aggregation instruction into an XSLT stylesheet,
> which might (or might not) be obvious to debug for somebody who isn't
> the original author.
I would prefer to keep details hidden away from the main
program outline, if they only affect one or a few components.
When something goes wrong with those components, you look at
those components, and the details are visible there.
I guess the implication then would be to use document()
for things that were truly local to your stylesheet.
> 2) theoretically, the non-document() methods of aggregation can be
> optimized not to create a full tree/table model of the document to be
> imported, which isn't the case using the document() function:
> a DOM-like
> in-memory representation will be created for both the imported and
> importing document. Using the include transformers, this
> might or might
> not be the case, i.e. the importing & imported document are
> SAX-streamed
> and no tree is built up (except when doing XPointer stuff with the
> XIncludeTransformer). Especialy for busy sites with large
> (aggregated)
> pages, this can make a huge difference.
This sounds like a good argument for the use of non-document()
methods of aggregation in certain situations.
In other situations though, e.g. where the documents
are small (as they are in my case), your web site's not busy,
(possibly also where XPointer is being used?), or where you
have more developer-expertise in XSL than in Cocoon sitemaps,
document() can be just as appropriate or more so.
I think Peter's email that started this thread was not saying
that only document() should be used, but rather asking,
why exclude document()?
Lars
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Crusading for the XSLT document() function
Posted by Robert Koberg <ro...@koberg.com>.
Hi Steven,
> -----Original Message-----
> From: Steven Noels [mailto:stevenn@outerthought.org]
> Sent: Saturday, October 18, 2003 12:09 PM
> To: users@cocoon.apache.org
>
> In my very personal opinion, I'm not convinced one should use document()
> for aggregation purposes, since:
>
> 1) it hides away the aggregation instruction into an XSLT stylesheet,
> which might (or might not) be obvious to debug for somebody who isn't
> the original author.
And it is more obvious in a sitemap.xml to someone other than the cocoon
author/developer?
Sure there are places for both! For example, layout configuration does not
concern a backend dev, but allows a frontend dev to separate concerns. And,
in my mind XSLT only provides the structure of the result where CSS provides
the styling (at least for HTML, and recently for things like MACR Flash).
>
> 2) theoretically, the non-document() methods of aggregation can be
> optimized not to create a full tree/table model of the document to be
> imported, which isn't the case using the document() function: a DOM-like
> in-memory representation will be created for both the imported and
> importing document. Using the include transformers, this might or might
> not be the case, i.e. the importing & imported document are SAX-streamed
> and no tree is built up (except when doing XPointer stuff with the
> XIncludeTransformer). Especialy for busy sites with large (aggregated)
> pages, this can make a huge difference.
Yes, in theory... but in practice I have not seen it, at least for my
situation. For me (CMS needs), I see slower results and more memory usage
(did you see Bruno's post to the dev list on the docs issue?) -- perhaps I
am doing things wrong...
The original poster's solution is very interesting as it lets me do things
without being inextricably tied to cocoon (I like to provide a simple exit
strategy), do things the same way I do them now and gain some of the
advantages I see in cocoon. I would have thought his way would be welcomed
as an alternative way that uses cocoon's strengths.
There is a large (?) group of XSLT users who could enter cocoon this way. I
don't see why there is an active effort to discourage (people do, as you may
know) the use of the document function based on unproven theory or feelings.
In the past there has been discussion of using the document function but it
has been dismissed as something that 'does not feel right' and people have
towed the line. Then, there was a discussion on a 'cool repository' (Reiser
FS) that seemed to reinvent the document function (as many of the examples
given demonstrated). It just seems minds have closed on the issue.
Thanks for your input -- sincerely,
-Rob
>
> HTH,
>
> </Steven>
> --
> Steven Noels http://outerthought.org/
> Outerthought - Open Source Java & XML An Orixo Member
> Read my weblog at http://blogs.cocoondev.org/stevenn/
> stevenn at outerthought.org stevenn at apache.org
>
>
> ---------------------------------------------------------------------
> 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: Crusading for the XSLT document() function
Posted by Steven Noels <st...@outerthought.org>.
Robert Koberg wrote:
> It is amazing that no one has commented on this post. Perhaps it is because
> the beta-omega developers do not want to show anything that contradicts the
> alpha developer (fear of agora Siberia perhaps...).
Don't you worry about Siberia - everybody is free to think whatever he
wants over here - but please keep in mind that not all devs are
subscribed to the user list, and vice-versa. So no FUD spreading please.
In my very personal opinion, I'm not convinced one should use document()
for aggregation purposes, since:
1) it hides away the aggregation instruction into an XSLT stylesheet,
which might (or might not) be obvious to debug for somebody who isn't
the original author.
2) theoretically, the non-document() methods of aggregation can be
optimized not to create a full tree/table model of the document to be
imported, which isn't the case using the document() function: a DOM-like
in-memory representation will be created for both the imported and
importing document. Using the include transformers, this might or might
not be the case, i.e. the importing & imported document are SAX-streamed
and no tree is built up (except when doing XPointer stuff with the
XIncludeTransformer). Especialy for busy sites with large (aggregated)
pages, this can make a huge difference.
HTH,
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
RE: Crusading for the XSLT document() function
Posted by Robert Koberg <ro...@koberg.com>.
It is amazing that no one has commented on this post. Perhaps it is because
the beta-omega developers do not want to show anything that contradicts the
alpha developer (fear of agora Siberia perhaps...).
You show a way to use cocoon and the document function in a harmonious (and
a very useful) way.
Are people simply closing their eyes to new ways (although standard and
accepted by some extremely intelligent people in XML/XSL) or have they
invested too deeply in _the cocoon way_ or do they simply refuse to think
about (and therefore feel no need to comment)?
----
One more benefit of using the document function as opposed to /proprietary/
cocoon ways is that you can perform simple transforms outside of cocoon or
even pick up your XSL and leave for another solution. -- NO LOCK IN --
-Rob
> -----Original Message-----
> From: Horsfield, Peter A. [mailto:peter.horsfield@ngc.com]
> Sent: Thursday, October 16, 2003 3:30 PM
> To: 'users@cocoon.apache.org'
>
>
> document('cocoon:/myinternalpipeline');
>
> SoC... Caching... Virtual URI space... Pipeline reuse...
>
> All it would take is for Cocoon to keep an eye out for calls to the
> SourceResolver, and perhaps for request parameters to be
> passed smartly. Better yet, force all document('...') requests be
> Cocoon internal protocol requests.
>
> Counter points:
>
> Source Pure XML -
> You get one pure XML source indirectly
> AND you get to use all the existing XML
> application specific tools for your other source.
>
> Aggregation -
> Aggregation is not the force for SoC it is presented as.
> It is good only for simple single level cases. As soon
> as you aggregate aggregations, you've lost the case.
>
> Speed -
> In an attempt to speed up processing, I removed the
> document function, and cincluded the data
> into the source. It made no difference. (Solaris 8 -
> there were other speed issues at the time).
>
> DOM / SAX -
> Aggregation pumps entire blocks of SAX events. This is
> fine, XSLT may be worse. But XSLT (or STX) implementations
> do have the freedom to optimize this stuff. The semantics of
> aggregation do not allow this freedom.
>
> Now if the developers of Cocoon think that using the document function is
> not a good use of Cocoon, then so be it. I think that in conjunction with
> the Cocoon protocol, it is a powerful feature that supports SoC.
>
> When it comes down to it aggregation and the document function do fulfil
> the same need. The only reason I would pick the XSLT document function
> over aggregation, is... it just feels right.
>
> After writing this all down, I think I've decided that both aggregation
> and
> document() suck in Cocoon. There has got to be a better way.
>
> Cocoon 3, perhaps.
>
> Regards,
>
> Peter
>
>
>
>
>
>
> ---------------------------------------------------------------------
> 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