Hi Werner,

my approach was to read about StAX before writing about my first look
at the patch.
This took longer than I expected. Sorry about that.

I wrote about my thoughts yesterday. But only related to the issue
2408 description
and not about the whole patch so those writings become quite useless...
After reading the whole patch and having a glance at the test cases here are my
impressions about my second look at the patch.

> Whatever comes to my mind when looking at this for the first time will make a 
> nice read.
> What's my opinion on that?

There was a discussion about futher extentions and usage scenarios:
* a feature that returns a list of mapped objects in one step
* XMLContext should/is? being used
* Queries that depend on child elements or attributs should be possible
* pull mapper is just one API to use "fragment mapper", there will be some
  extended APIs for doing those queries
* global and local elements are defined with XML Schema and code is being
  generated for the XSD
* differences between XMLCassDescriptor when generated from XSD, defined by
  mapping and read by reflection.

Does support for StAX for unmarshalling within the XML data binding framework
itself mean that the approach of transforming between StAX events to SAX events
has to be changed? Same question for the possibility to switch between
SAX and StAX.
After reading some tests I think it's saying that the fragmentmapper module
should be merged within the XML data binding framework. or is it the other way
round because the newest patch creates an own module? Honestly I am not sure
if that would make sense...
Should the user be able to invoke something like unmarshal(Stream,
Path expression)?
Why does the project description say StAX for un-/marshalling when
there will be
no support for marshalling?
Why is it 'necessary' to separate concerns in Castor XML?
I'm not sure whether I get the gsoc2010 project description or not...

As discussed earlier following extensions might be useful:
* extending fragmentmapper to process queries that depend on child-elements or
attributs,
* using JavaCC instead of AntLR

Those were my impressions -mostly questions- when reading about the patch.

I want to to my first proposal as soon as the above mentioned
questions are clear to me.

Thanks for spending your time and your help,
Philipp

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to