Kohsuke Kawaguchi wrote:
>
> I know the exact package name is still under the discussion, but
> shouldn't there be a link from the FI web site to the javadoc of the API
> that FI exposes?
>
Yes, we should having something ready for early next week after we have
moved some of the classes.
> I've been doing that for many other projects that I involve (see
> http://stax-utils.dev.java.net/ for example), and as usual I have an
> automated system to do this regularly.
>
> I'm happy to set one up for FI if that suits everyone.
>
That would be great.
>
>
> And actually my question was whether FI serializer has a native API.
> We've been talking about integrating FI into JAXB RI, but I'm not sure
> if I want that code to live inside the FI, because it depends on a lot
> of internals of the JAXB RI.
>
> It seems to me that it is better to keep that code inside the JAXB RI. I
> probably want some FI expert to write the initial version, but once
> that's done it shouldn't be hard to maintain that by the JAXB team,
> perhaps with an occasional help from the FI project.
>
OK, that sound good.
> This assuming that FI has (or is going to have) a well-known native API,
> committed for a compatibility, that allows fast serialization to FI.
>
All serializers inherit from the Encoder class that has many methods to
encode various information items and has buffering support.
All parsers inherit from the Decoder class, but this is quite light
weight as different parsers have different models. A lot of the parser
work is done by using the arrays in DecoderStateTables class.
I did not plan that the Encoder would be part of the initial API, but i
think this is something we need to consider so that there is a clean
contract between FI and JAXB.
For now any specific JAXB implementation should extend from the Encoder
class and JAXB related functionality could be added to the extended
class or generically to the Encoder. The basic DOM serializer is about
250 lines of code (supporting EIIs, CIIs, Comment IIs and PI IIs) as
most of the work is performed by the Encoder class.
> Is this going to be the case? Any thoughts?
>
Perhaps we can evolve the design of this through the experience with
integration into JAXB? as this API is not as immediately crucial (in
terms of time) to most developers as the encoding algorithms and
vocabularies are.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109