Santiago Pericas-Geertsen wrote:
>
> On Feb 3, 2005, at 12:22 PM, sandoz_at_dev.java.net wrote:
>
>> User: sandoz
>> Date: 2005/02/03 09:22:00
>>
>> Log:
>> Moved FISource and FIResult to the api.sax package.
>
>
> Couple of comments:
>
> o I don't believe we want to associate FISource and FIResult with SAX.
> FISource and FIResult are implemented using SAX, but that is just a
> detail (the constructors take a stream in both cases). If we change the
> implementation, we don't want to move them to another package.
>
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 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).
Maybe these classes should be abstract and then we have implementation
classes for SAX?
> 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.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109