--- Paul Sandoz <Paul.Sandoz_at_Sun.COM> wrote:
> Hi Aaron,
>
> I think the Cursor API is the right fundamental
> abstraction to extend
...
> services stack simply because and we found it offers
> no advantage over
> using just the Cursor API).
This has been my experience as well, although I do
know
some users have different views on this.
I think that proper layering of things would have
been to further separate two parts: esp. since
generic Event API implementation is quite easy
to write.
I think what it comes down is a simple split, where
people working on libraries, toolkits and frameworks
want to avoid adding unnecessary overhead (Event API
incurs perhaps 30%-40% automatic overhead, without
adding anything beyond non-transiency, and simple
objectification -- both of which are nice for apps,
but often not very useful for toolkits).
> One way the cursor API could be extended is to have
> additional iface
> that allows one to access sub-events of character
> and access things as
> integers etc. e.g. readTextAsInteger,
> readTextAsArrayOfIntegers. Such an
> the API could work for both XML, FI and other binary
Yes, this is something for which many people have
expressed interest. And I am finally also planning
to play with this, in scope of Woodstox 4.0, and its
"Stax2" extension set (which is done similar to
how StaxEx and FI approach the problem, at some
level).
It is important to also keep in mind the
bi-directional
aspect, since in general at least 1/3 of time used by
low-level xml processing (read/write) is on
output side: for some implementations even more
(and I think FI actually belongs in this category,
as its output logics are more sophisticated than
that of textual xml output).
> I believe the right approach is to experimentally
> develop such
> extensions in the FI workspace using the FI
> implementation. After good
> implementation experience i think we should
> encourage this to be part of
> a generic interface e.g. part of stax-ex project
> [1], which currently
> extends the StAX cursor API in a limited manner, and
> encourage XML
> implementations e.g. SJSXP and Woodstox. Then
I agree. I think it is a good idea to experiment with
extensions first, and after knowing more, try to
standardize (either via JSR process, or de facto
standards, or both).
> binding technologies, e.g.
> JAXB implementations, can potentially take advantage
> of such
> implementations and the interface to improve binding
> performance when
> using XML and Binary XML parsers. (Note that i think
> it important to
> keep in mind the binding use-case. In such cases a
> binder will often
> have an expectation of what the next event will be.)
Yes. I would even say that type-aware
accessors/mutators
are almost exclusively needed for data binding use
case.
But there they are beneficial.
There is also one part of existing Stax API many
developers
seem to overlook: that of accessing 'raw' text array
(XMLStreamReader.getTextCharacters()).
Calling this method (and 2 related methods to get
offset,
length, within that buffer) avoid construction of a
String (which is not just mem alloc of String, but
also allocing of char[], copying data over etc).
So even within existing API many toolkits could
optimize
handling of non-textual values.
It would still be beneficial to add typed accessors,
of course.
> There are others on this list who have very good
> experience with StAX
> and could provide invaluable feedback in any APIs
> extension you may
> propose. So i think you are in good company :-)
;-)
One more thing: this is also something that could
be discussed on "generic" stax list
(stax_builders_at_yahoogroups.com).
-+ Tatu +-
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html