Arkin wrote: > As for serializing Node that happens to be an Attribute, keep in mind > that we're trying to define an API used by a lot of serializers. The > question that should be raised is: would it be trivial for them to > support it? Would a PDF serializer support that?
Perhaps not but you're precluding other types of serializers. Here's an idea: how about a way to query the serializer to ask it for which DOM nodes it supports serialization? For example: public boolean supportsNodeType(short nodeType); In the case where the serializer instance doesn't support serializing that node type, it could throw an exception. > XSLT defines an output method which has one of three names xml, html, > text or a qualified name for additional methods (like PDF, SVG, etc).It > then defines media-type as a separate value. I don't like it, but it's > part of the spec and the serializers have to support that for the sake > of XSLT processing. But <xsl:output> is not required to be observed by an XSLT processor. And there's nothing that says that a general serialization API has to follow exactly what the XSLT specification details. As long as there is a way to map from what an XSLT document may specify via <xsl:output> to our serialization scheme, I don't see a problem. > Not the best design, I agree, but one which follows the XSLT specs. Is this a strict design goal? I'd rather have a good design that *allows* XSLT output "hints" than design around that optional part of the XSLT specification. > No, the serializer API does not assume markup, it was designed to > support PDF, JPEG, and other binary formats. An implementation should by > default support the three common text formats, but the API is designed > so other formats can be introduced as well. So you do not see the usefulness of separating binary from character serializers? > I don't see why the serializers should not support both. An output > stream is also used in many applications for character output (even if > we both agree they should use Writer). It should certainly be understood > that a GIF serializer only uses setOutputStream, but then, a PDF > serizlier to Base64 encoding could use either one. Just because ASCII is a one-byte encoding doesn't mean that OutputStream *should* be used. It may but Writer is definitely the way to go even if you're outputing ASCII, ISO Latin 1, or any other one-byte encoding. (Even ISO Latin ? would be wrong due to various mappings from Unicode to the single byte form if you use an OutputStream.) > some transformations like that make sense. With that in mind, the > serializer API is part of the XSLT API and should support outputing of > all such possible transformation. Huh? Perhaps we should go back to listing the design goals of the serialization API. I know that Scott wrote his own pretty printers when he wrote LotusXSL but I didn't realize that the serialization API was being designed around Xalan. -- Andy Clark * IBM, JTC - Silicon Valley * [EMAIL PROTECTED]
