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: SAT API Proposal (Draft 3) (was XSLT API)
Date Thu, 10 Feb 2000 18:46:04 GMT

Kay Michael <Michael.Kay@icl.com> wrote:
> You've put getAssociatedStylesheet() as a method on Processor. I can't
see
> what the "given document" is.

Sorry, copy & paste error.  Read:

  /**
   * Get an InputSource specification that is associated with a
   * given document specified in the source param,
   * via the xml-stylesheet processing instruction
   * (see http://www.w3.org/TR/xml-stylesheet/), and that matches
   * the given criteria.
   * @param media The media attribute to be matched.  May be null, in which
   *              case the prefered stylesheet will be used (i.e. alternate
= no).
   * @param title The value of the title attribute to match.  May be null.
   * @param charset The value of the charset attribute to match.  May be
null.
   * @returns An InputSource that can be passed to createStylesheet method.
   */
  public abstract InputSource getAssociatedStylesheet(InputSource source,
                                                      String media,
                                                      String title,
                                                      String charset)
    throws SATException;

> I feel OutputProperties should contain only those properties that
directly
> reflect xsl:output

Well, in practice you're probably right, but the general idea is that
org.xml.transform should not be specific to XSLT.

> 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.)

Yep, the QName issue again, which arises in quite a few cases.  We need a
QName object that contains a name string, namespace string, and optional
originating prefix (needed not for this case but there are some places
where this might be useful).

> 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.

Yep, done.  I also have a request for protocol registration for
setURIResolver, which I didn't get around to.  Does this feature sound good
to you?

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

See my other response to you.  I think we should nix Result.

> 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.

I think you would use the Serializer interface for this.

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

If we get rid of "Result", that does away with these typos too!

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

Steve Muench suggested "TRAX", which I like a lot.  TAX has negative
connotations.

-scott






Mime
View raw message