Santiago Pericas-Geertsen wrote:
> 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?
Yes.
> These classes are
> needed for JAXP intergration, and that goes beyond the transformer API.
> For example, you can use them with the validation API.
OK.
> It's not about
> performance, it's about integration IMO. If you don't care about
> integrating into JAXP, ignore them!
>
My concern is that these classes will get used while not understanding
the consequences of such use. So we need to document carefully. Seems
that to do all of this properly we need to integrate better into the
JAXP implementation.
For more advanced use we can have explicit SAX functionality for
performant integration. Just simple helper classes really.
>
>>> 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.
>
OK. If the goal is to create an API which is completely separate from
the implementation (which i think will benefit us and developers in the
long run) we will need factory mechanisms for parsers and vocabularies.
We have already integrated into the factory mechanims of StAX, but i am
wondering if an explicit FI factory mechanim is required here, as most
users of the StAX APIs will expect an XML parser/serializer to be
returned from the StAX factory for the platform in use.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109