OK. Let me come up with a cleaner serializer API without all the extra
baggage and send you all a proposal. I'll figure out something for CDATA
and also specify namespace for the non-standard methods.

arkin


Kay Michael wrote:
> 
> > Can I still just use "fop" and not write in a URI?
> 
> According to the spec, method="fop" is illegal in the xsl:output element;
> whether it should be illegal in the OutputProperties API is debateable.
> Either way, xsl:output allows my:fop, where my is a namespace prefix in
> scope, so OutputProperties ought to allow that too; and it needs to record
> the URI and local name.
> 
> > > cdata-section-elements is defined as a whitespace-separated
> > list of qnames.
> >
> > Two options:
> >
> > 1. Pass a list of uri^local-name
> >
> > 2. Pass the uri as one argument, the list of local-name as another
> >
> 
> My first instinct is to say we should handle names in the same way as SAX2,
> which is as three parameters: localName, uri, and "rawName". But SAX2 never
> seems to have a method that returns a name, so it can get away with it.
> Having separate calls getMethodLocalName() and getMethodNamespaceURI(), and
> getCDATALocalNames() and getCDATANamespaceURIs seems terribly over the top.
> 
> My second instinct (and what I do in Saxon) is to define a class Name. I'd
> have done it that way in SAX, too. I know David Megginson doesn't like
> having lots of little classes, but my instinct is to go for clarity and not
> worry about the lost microseconds.
> 
> The composite name approach (uri^localname) is really a bit yukky, but it
> might be a reasonable compromise here (at least on getMethod() /
> setMethod()), because the presence of a URI will be exceptional.
> 
> Perhaps we ought to think ahead, this API is going to grow to handle
> extension functions and elements etc, and it ought all to be done the same
> way. I think a Name class makes sense.
> 
> Mike Kay