cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Assaf Arkin <>
Subject Re: XSLT API Proposal (Draft 2)
Date Mon, 07 Feb 2000 19:48:58 GMT
> OutputProperties. This now looks quite similar to Saxon's OutputDetails
> class, but it has some stuff which I don't really need or want: mine is much
> more closely a direct mapping of the xsl:output properties. (I even keep the
> values as yes/no strings rather than booleans, though I wouldn't defend that
> strongly: it gives me the option to support additional values in a subclass,
> e.g. the <saxon:output> extension elements now permits indent="3".) If this
> is changed to be a pure data class with only those properties corresponding
> directly to xsl:output I can live with it being a concrete class rather than
> an interface.

OutputProperties was modeled after xsl:output, plus some additional
stuff requested by people.

Indentation is an on/off thing since xsl:output defines is like that and
most developers simply want an on/off switch (on when debugging, off in
production). But you can specify the number of spaces to use (o means no
identation) and the line width to wrap at (0 means no wrapping), so you
do get that level of flexibility.

I think the only other addition are the unescaped elements, per specific
request by several XML developers.

> So I'm having trouble understanding the distribution of properties/methods
> between XSLTResultTarget and OutputProperties (e.g. why is setEncoding() on
> both); and I'd be a little inclined to try replacing XSLTResultTarget with
> an OutputMethod class.

I assume convenience. Keep in mind that some developers are using
OutputProperties directly to control the output, not everything goes
through XSL. The three most requested arguments in a constructor were:

* Encoding
* Method
* Indentation on/off


> Mike K

Assaf Arkin                                 
CTO, Exoffice Technologies, Inc.              

View raw message