> In the case where the serializer instance doesn't support > serializing that node type, it could throw an exception.
Why? I mean, how many serializers do you expect to be able to serialize an attribute or a text node? When will you use that functionality? > 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. I was just following the XSLT guidelines since they are well specified. There is no specification of how serialization should occur outside of the XSLT spec, which is pretty clear about that. I assume if there ever was one, it would borrow from the XSLT spec, so the naming would be in conflict with such a specification. > 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. Once again, I don't have to stick to XSLT specs, but I think there was a lot of work to define the spec in that area and any W3C proposal for just specifying serialization will follow the same names and ideas. > > 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? No. > 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.) I didn't say *should* I said *would*. I actually use OutputStream with the serializers, I let the serializer pick the Writer for me based on the encoding. Otherwise, I have to create a Writer and make sure to use the same encoding. More lines of code, same end result. If you are outputing to a file, I think new FileOutputStream is a better approach than new FileWriter, let the serializer pick the Writer for you. > > 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. Not around Xalan, just to support Xalan, so you can plug different serializers that are not existing in Xalan into Xalan. I think we got our messages crossed at this point. The serializers should fulfill the following: * Support XML, HTML, Text * Support any other output format (textual, binary) * Allow an XSLT processor to use them, so you can extend the capabilities of an XSLT processor by creating new serializers * Allow them to be used without an XSLT processor In keeping with that separation, extensiblity and useability, I tried to do the following: * Define an API that can take care of all the serialization details for XML, HTML, Text * Make the API sufficient enough to support other output formats (textual and binary) * Allow the API to be extended to support other output formats that require more properties/methods * Make the API separate from the TRAX API, yet make sure it's sufficient for what XSLT needs The decision to support Xalan had little affect on the definition of the API, it comes free if the API is independent of any particular implementation details and well defined. The decision to stick to XSLT spec was not brought up by Xalan either, only by the fact that the XSLT spec specifies how serialization should occur. The fact that there are some differences between the XSLT spec and the Java spec are merely a point of conflict that do not affect just the serializer. Consider that setContentType in the Servlet API is modeled after the HTTP content-type. The fact that XSLT adopted media-type and not content-type is a mistake in my opinion, but this is a conflict between XSLT and HTTP as well. If XML 2.0 would (not saying that it will, just an example) add content type specification to the XML document declaration, would that be media-type or content-type? Should an XML parser use the XML 2.0 term, or the Java term? arkin > > -- > Andy Clark * IBM, JTC - Silicon Valley * [EMAIL PROTECTED] -- ---------------------------------------------------------------------- Assaf Arkin www.exoffice.com CTO, Exoffice Technologies, Inc. www.exolab.org
