On Feb 4, 2005, at 3:53 AM, Paul Sandoz wrote:
> My thoughts on moving this to the SAX api were that i wanted modify
> these classes to reuse the parser/sereliazer but once this is done we
> expose the SAX implementation details.
>
> For the SAXSource the constructors are:
>
> SAXSource()
> SAXSource(InputSource inputSource)
> SAXSource(XMLReader reader, InputSource inputSource)
>
> How can we take a similar approach without exposing details of SAX?
I'm not sure what's the use case you have in mind. I think of FISource
and FIResult as akin to StreamSource and StreamResult --FI is just
another serialization after all-- that just happen to be implemented as
an extension of SAXSource and SAXResult for convenience and ease of
integration into JAXP. Thus, I don't see the need to expose any SAXy
stuff.
> I think these classes could have more value if reuse of
> parsers/serializers were allowed otherwise there is a performance hit
> (hence why we currently do not use them in the Japex tests) thus i
> would only recommend using them in the most simple of scenarios (which
> is why they are used by classes in the tools package).
I guess you have the transformers in mind, right? These classes are
needed for JAXP intergration, and that goes beyond the transformer API.
For example, you can use them with the validation API. It's not about
performance, it's about integration IMO. If you don't care about
integrating into JAXP, ignore them!
>> o com.sun.xml.fastinfoset.api.sax is a mouthful for API classes.
>> Maybe we should move these into javax.xml... even though they are not
>> officially part of the platform.
>>
>
> We could create org.xml.fastinfoset ?
>
> I would eventually like to separate the API from the implementation
> somewhat and have as a separate project with its own jar.
I agree, that's a good idea.
-- Santiago