StAX extension for FI

[Aaron_Anderson]

 I have read several references about extending the StAX API to support FI built-in algorithms. Is there any time line for this to occur?    
   
While the StAX cursor API  is rigidly typed for Strings it seems the event API is more extensible. According to    
http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html   
   
"You can create subtypes of XMLEvent that are either completely new information items or extensions of existing items but with additional methods."  
   
I am interested in using StAX in conjunction with FI in order to parse in an XML document that contains numerous float and integer arrays. I would like to leverage the parsing model of StAX while still being able to access the raw FI primitive data arrays read into memory and avoid decoding them as strings.  
   
Would it be feasible to create a new version of the StAXEventReader that would emit custom XMLEvents that would contain additional methods to access the underlying FI data?  
 
For example,  
 
 XMLEventReader r = new StAXEventReader2(new FileInputStream(filename));  
 float[] data;
 while(r.hasNext()) {  
     XMLEvent e = r.nextEvent();  
     if (e instance of Characters){
         if (e  instanceof  FICharactersEvent){
             data=((FICharactersEvent)e).getFloatData();
         }else{  
              data=myFloatStringParserMethod((Characters)e).getData());
           }
    }
 }  
 
 
Any comments?  
 
 
 




 
____________________________________________________________________________________
No need to miss a message. Get email on-the-go
with Yahoo! Mail for Mobile. Get started.
http://mobile.yahoo.com/mail

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Paul Sandoz]

Hi Aaron,

I think the Cursor API is the right fundamental abstraction to extend
(for example look at MS's .Net reader API). Any Event API extensions can
be built on top of the Cursor API extensions. In my experience at least
the Event API is not used much (we have never used it in our Web
services stack simply because and we found it offers no advantage over
using just the Cursor API).

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 XML formats. (Note
that such functionality may have to take into account potentially tricky
edge cases such as in-fixed comments and processing instructions.)

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 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.)

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 :-)

Paul.

[1] https://stax-ex.dev.java.net

Aaron Anderson wrote:

> I have read several references about extending the StAX API to
> support FI built-in algorithms. Is there any time line for this to
> occur?
>
> While the StAX cursor API  is rigidly typed for Strings it seems the
> event API is more extensible. According to
> http://java.sun.com/webservices/docs/1.6/tutorial/doc/SJSXP3.html
>
> "You can create subtypes of XMLEvent that are either completely new
> information items or extensions of existing items but with additional
> methods."
>
> I am interested in using StAX in conjunction with FI in order to
> parse in an XML document that contains numerous float and integer
> arrays. I would like to leverage the parsing model of StAX while
> still being able to access the raw FI primitive data arrays read into
> memory and avoid decoding them as strings.
>
> Would it be feasible to create a new version of the StAXEventReader
> that would emit custom XMLEvents that would contain additional
> methods to access the underlying FI data?
>
> For example,
>
> XMLEventReader r = new StAXEventReader2(new
> FileInputStream(filename)); float[] data; while(r.hasNext()) {
> XMLEvent e = r.nextEvent(); if (e instance of Characters){ if (e
> instanceof  FICharactersEvent){
> data=((FICharactersEvent)e).getFloatData(); }else{
> data=myFloatStringParserMethod((Characters)e).getData()); } } }
>
>
> Any comments?
>
>
>
>
>
>
>
>
> ____________________________________________________________________________________
>  No need to miss a message. Get email on-the-go with Yahoo! Mail for
> Mobile. Get started. http://mobile.yahoo.com/mail
>
> ---------------------------------------------------------------------
>  To unsubscribe, e-mail: users-unsubscribe@... For
> additional commands, e-mail: users-help@...
>

--
| ? + ? = To question
----------------\
    Paul Sandoz
         x38109
[phone]

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Tatu Saloranta]

--- Paul Sandoz <Paul.Sandoz@...> 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@...).

-+ Tatu +-




 
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...