cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Scott Boag/CAM/Lotus" <Scott_B...@lotus.com>
Subject Re: XSLT API Proposal
Date Sat, 05 Feb 2000 17:38:27 GMT

K Karun <kkarun@us.oracle.com> wrote:
> Hmmm... I don't see any advantage of having XSLTSourceDocument. The
> function getAssociatedStylesheet() can belong to XSLTInputSource.

I see what you are saying, in that XSLTSourceDocument seems a lot like an
XSLTInputSource.  But, I don't think that XSLTInputSource should have any
behavior associated with it, in the tradition of the SAX InputSource
object.  As soon as you add behavior, then that behavior would require
vendor-specific code, or you would have to mess with abstract classes.

I'll try putting this stuff in terms of design patterns, in order to
abstract things a bit:

<design-patterns module="XSLT">

<pattern>
<pattern-name>XSLTExecContext</pattern-name>
<potential-alternate-name>XSLTProcessor</potential-alternate-name>
<intent>Serve as session specific coordination for XSLT
processing.</intent>
<responsibilities>Process XSLT input into a Transform Object, handle
session-specific features, such as setParam.</responsibilities>
<thread-safety>One instance per thread.</thread-safety>
<note>There is a problem of this pattern really doing three things: 1)
creating a Transform object via an input specification, 2) creating a
Transform object via SAX events, and 3) handling session-specific
properties.  It could be broken up into two or three objects, although my
current thinking is that this would complicate things.</note>
</pattern>

<pattern>
<pattern-name>XSLTInputSource</pattern-name>
<intent>Serve as a single vendor-neutral object for multiple types of
input, so there can be simple process method signatures.</intent>
<responsibilities>Act as simple data holder for System IDs, DOM nodes,
streams, etc.</responsibilities>
<thread-safety>Threadsafe concurrently over multiple threads for read-only,
must be synchronized for edit.</thread-safety>
</pattern>

<pattern>
<pattern-name>XSLTResultTarget</pattern-name>
<potential-alternate-name>ResultTarget</potential-alternate-name>
<intent>Serve as a single object for multiple types of output, so there can
be simple process method signatures.</intent>
<responsibilities>Act as simple data holder for output stream, DOM node,
DocumentHandler, etc.</responsibilities>
<thread-safety>Threadsafe concurrently over multiple threads for read-only,
must be synchronized for edit.</thread-safety>
</pattern>

<pattern>
<pattern-name>XSLTSourceDocument </pattern-name>
<potential-alternate-name>SourceTree</potential-alternate-name>
<intent>Serve as a representative of a XSLT Source Tree, abstractly already
parsed.</intent>
<responsibilities>Deliver information about a Source Tree that an XSLT
processor would be interested in.</responsibilities>
<thread-safety>Threadsafe concurrently over multiple
threads.</thread-safety>
</pattern>

<pattern>
<pattern-name>OutputFormat</pattern-name>
<intent>Need to deliver xsl:output information to the API, so that
processor-neutral result tree handlers can use it.  Also need to allow
output properties to be given defaults by the caller (is this really
needed?), and the caller must be able to override stylesheet
specifications.</intent>
<responsibilities>Serve as a data object for holding information about
result-tree serialization.</responsibilities>
<thread-safety>Threadsafe concurrently over multiple threads for read-only,
must be synchronized for edit.</thread-safety>
</pattern>

<pattern>
<pattern-name>URLResolver</pattern-name>
<intent>An interface that can be called by the processor to for turning the
URIs used in document() and xsl:import etc into an XSLTInputSource
.</intent>
<responsibilities>Returns an XSLTInputSource, given a
URI.</responsibilities>
<thread-safety>Needs to be threadsafe concurrently  over multiple
threads.</thread-safety>
</pattern>

<pattern>
<pattern-name>XSLTException</pattern-name>
<intent>Need XSLT specific exception that can be caught by a catch
clause.</intent>
<responsibilities>Same as for SAXException.</responsibilities>
<thread-safety>Instance per thread.</thread-safety>
</pattern>

<pattern>
<pattern-name>Transformer</pattern-name>
<intent>An object that represents the XSLT source that is thread-safe
per-instance running concurently over multiple threads.</intent>
<responsibilities>Processes a source tree to a result
tree.</responsibilities>
<thread-safety>Threadsafe concurrently over multiple threads once
construction is complete.</thread-safety>
</pattern>

</design-patterns>

-scott






Mime
View raw message