cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kay Michael <>
Subject RE: SAT API Proposal (Draft 3) (was XSLT API)
Date Thu, 10 Feb 2000 11:26:31 GMT
Great stuff! The names are much better now, as is the substance.

I need to study SAX2 more carefully to understand how the ContentHandler
interfaces work, but meanwhile, some comments on the rest:

You've put getAssociatedStylesheet() as a method on Processor. I can't see
what the "given document" is.

I feel OutputProperties should contain only those properties that directly
reflect xsl:output, and that non-standardized properties used by Xalan or
other serializers should be supported either via a SAX2-like getProperty()
mechanism (useful for extensibility anyway) or by subclassing.

OutputProperties: if getMethod() returns anything other than xml, text, or
html, then the value must have a namespace prefix and there is a need to
turn this into a namespace URI. (We could define that the returned string is
in a form such as uri^local-name.)

OutputProperties: there shouldn't be any assumption that the thing being
serialized is a DOM. The logic for examining the tree and choosing a default
method is misplaced; even though it only implements what the spec says, it
belongs in an implementation and not in a vendor-neutral API. Either
OutputProperties should be data-only, or it should be an interface. 

OutputProperties: on the methods for handling the list of CDATA elements, I
can't see how namespace prefixes are supposed to be handled. Again we could
say that the names are expressed as uri^local-name.

Transformation: setURIResolver() here can only specify the resolver for
document(), it's too late for xsl:import and xsl:include. Need a separate
setURIResolver() on Processor (presumably) to define the one used for the
stylesheet, this could also act as a default for the Transformation.

I'm not sure whether it's right that Transformation.setOutputProperties()
should override xsl:output, or whether it should just provide defaults for
unspecified properties. The conformance rules don't constrain us, it's more
a matter of principle. Shame that xsl:output properties aren't AVT's. My
instinct would be to say it's equivalent to importing another xsl:output
statement with lower import precedence than those in the stylesheet proper.
I hate passing such decisions to the user, but perhaps there's a case here
for both options, for the properties to have either highest precedence or
lowest precedence.

I'm still confused about why setEncoding() is on both Result and
OutputProperties, and how they relate.

If you use setContentHandler() on Result, are the OutputProperties ignored,
or can they be passed to the ContentHandler? I think it's important that a
user-written output method should have access to the OutputProperties, just
as the system-supplied methods do.

in Result, some of the javadoc comments are wrong.
in Result, there is an instance variable filename which is unused.

> Rather, it should be a Transformation API.  
> Therefore I am proposing renaming it to be the "Simple API for 
> Transformations" (SAT for now) 

Funny that, I was going to propose TAX, Transformation API for XML.


View raw message