[Fwd: Re: XSLTInputSource]

[Keith Visco <kv...@exoffice.com>]

Scott Boag/CAM/Lotus wrote:

> Keith Visco <kv...@exoffice.com> wrote:
> > I think we should remove the DocumentHandler interface from the
> processor. The XSLTProcessor, should  only
> process, but not implement the DocumentHandler.
>
> Let me sleep on it.  Curious as to what other's think.
>

ok....don't sleep too much, it won't be fair.

>
> > Do you think it would be difficult to move the DocumentHandler interface
> out from XSLT processor?
>
> Not too hard, it's actually pretty simple code for the moment (it just
> creates a DOM, then plays it back... eventually it needs to be worked on so
> that it processes with the DTM, and can do the transforms incrementally
> while the SAXEvents are occuring).
>

Yes we should get it using the DTM, we don't want to build a complete
DOM
before we begin processing.

>
> However, you will have to pass the processor to the constructor of
> XSLTDocumentHandler.

Hmmm....why?

Personally I would like to see the XSLTDocumentHandler track the
creation of
the DOM nodes (incrementally) and index them for Ids as well as
Attribute
node/Parent relationships.

Once #startDocument has been called, or once #startElement has been
called for
the first time without a prevous call to #startDocument, a new Document
will be
created and immediately available to the XSLT processor.

A  methods such as:

boolean completed(Node node);

can be used to determine if a given node has been completed, a call to
this
method using the Document node, will signal the entire document has been
read
in and indexed.

Also a #getParentNode(Node node) would return the parent of the given
node,
including attributes

and a #getElement(String idref) would return the element that has the
given ID.




>
>
> > Yes, I agree somewhat. But it might make more sense to do an
> >
> > XSLInputSource(Stylesheet stylesheet)
>
> The problem with this is that this same input source is used for the input
> XML parameter.  I think this is pretty ugly, because the caller could
> create an XSLTInputSource with a stylesheet, pass it as the input XML
> parameter, and have it make absolutely no sense.  It would be better to
> have a:
>
>   public void process( Stylesheet stylesheet,
>                        XSLTInputSource xslStylesheet,
>                        XSLTResultTarget resultTree);
>
> process variation.
>

Yes you are correct, I was thinking only in terms of the Input
stylesheet when
I wrote that. This method should be added to XSLTProcess.


> > Well, removing the DocumentHandler methods will help reduce that.
>
> No, it's not the number of methods on the implementation that bothers me,
> it's the number of methods in the interface, which doesn't include the
> DocumentHandler methods.

Oh ok, I'll have a look at that.

>
> > One typically doesn't percieve a self-applying stylesheet.
>
> I wonder why?  Is this because the stylesheet is perceived as pure data?
>

Perhaps....I see the stylesheet as a set of rules, and I see a processor
applying those rules. I don't see the logic of the processor contained
within
the set of rules. Perhaps for efficiency the rules should know how to
process
themsevlves...but I still like to think in terms of a separation between
the
two.

> Removing the process call for stylesheet makes it so the user, when passing
> around the stylesheet, has to specifically create a processor in order to
> do the transform.  Remember the processor tends to be a rather temporary
> object (unlike the stylesheet).  The processor tracks state, and is not
> safe to use across multiple threads, unlike the stylesheet, which is
> stateless.

Actually the Processor itself should be pretty stateless, and it should
take a
State object which can be persisted or not.

#process(XSLTInputSource, Stylesheet, XSLTResultTarget);
#process(XSLTInputSource, Stylesheet, XSLTResultTarget, ProcessorState);

The ProcessorState would contain the top level variable declarations:

ProcessorState#setVariable("currentDate",  (new Date()).toString());


> Just thinking out loud, not taking a stand either way.

It's good to think out loud, it lets other people know what's on your
mind, and
perhaps to comment on it.  And since the API is what EVERYONE has to
live with
people should feel free to speak up and comment on it. The actually
implementation most people will never see, and for the few that do look
at it,
only a fraction will ever comment. But everyone must use the API
so....API
suggestions are more than welcome.

>
> > I'm not sure, I still think we should leave this alone. Though we may
> need an XSLTExcuctionContext, or
> merely a ProcessorContext (this is what I have in XSL:P) if there isn't
> already one.
>
> Often I call the variable for XPathSupport the "execContext".  This is
> because that is what I'm using it for, so maybe this class is what should
> be renamed.  But, strictly speaking, the XSLTProcessor *is* the top-level
> execution context for the transformation, by it's very nature.
>

Perhaps. Here are my thoughts. An XSLT processor should be reusable. It
should
put all non global information into a state object (which may or may not
be
persistable).
This helps reduce overhead in an environment where a lot of XSLT
processing may
be going on, like in Cocoon.

The XSLT processor should set up only some global references such as the
XML
parser it's using, the XPath library and any extension functions and
perhaps
some top-level variables which can be made available to ALL stylesheets
being
processed using the current processor, such as XSLT processor name and
version.

And then it should have a decent set of process methods which support
most of
the different variations that a user will need. The XSLTInputSource is
nice
because it greatly reduces the amount of variations. I never did that
for
XSL:P, so it had lots of #process methods.


--Keith