[Xmlbeans Wiki] Update of "V2Features" by JanePage

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Xmlbeans Wiki" for change notification.

The "V2Features" page has been changed by JanePage:
http://wiki.apache.org/xmlbeans/V2Features?action=diff&rev1=19&rev2=20

  
   * '''Performance''' - As in XMLBeans V1 performance is paramount V2.  Since XMLBeans always loads an XML Store and then provides a binding view on to the store some amount of additional overhead, compared to other Java/XML binding frameworks that unmarshal directly to Java objects (but throw away XML Infoset info that doesn't fit into the Java objects).  This makes the performance bar all the higher for XMLBeans so that the tradeoff for additional functionality and information is minimal.  The primary focus for runtime performance is in the area of the XML Store although there are other factors to consider as well (for example parsing).  Every effort will be made to make the XML Store as highly performant as possible.  Benchmarks against related technologies need to be created (with source for the benchmarks available of course) and performance tests included in the test suite to assure that performance regressions do not occur in the development process. 
  
-  * '''Compilation Performance''' - In XMLBeans V1 compilation, while very performant, was essentially fully batch oriented.  If one minor change occurred to a single XML Schema amongst a whole set of XML Schemas that are submitted to the XMLBeans schema compiler the entire XMLBeans schema type system and generated classes were recreated.  In other words XMLBeans has been unable to take advantage of compilation work that already occurred.  For XMLBeans users with large numbers of XML Schemas, or IDE's integrating XMLBeans, compilation time can be problematic.  In XMLBeans V2 major steps towards addressing this issue will be implemented.  When doing an XMLBeans compile you should be able to pass in existing XMLBeans compiled artifacts (probably not a jar, most likely an exploded directory, or perhaps an in memory representation) and the XMLBeans compiler would do only the ''incremental'' work necessary to rebuild the type system and the java classes.  In V2 this will likely show up as 1) only the java classes that change should be compiled and replaced and 2) incremental XML Schema compilation at the '''namespace''' level.  Our opinion is that the doing incremental compilation at the '''type''' level is too low level and too difficult to implement (at least in V2).  
+  * '''Compilation Performance''' - In XMLBeans V1 compilation, while very performant, was essentially fully batch oriented.  If one minor change occurred to a single XML Schema amongst a whole set of XML Schemas that are submitted to the XMLBeans schema compiler the entire XMLBeans schema type system and generated classes were recreated.  In other words XMLBeans has been unable to take advantage of compilation work that already occurred.  For XMLBeans users with large numbers of XML Schemas, or IDE's integrating XMLBeans, compilation time can be problematic.  In XMLBeans V2 major steps towards addressing this issue will be implemented.  When doing an XMLBeans compile you should be able to pass in existing XMLBeans compiled artifacts (probably not a jar, most likely an exploded directory, or perhaps an in memory representation) and the XMLBeans compiler would do only the ''incremental'' work necessary to rebuild the type system and the java classes.  In V2 this will likely show up as 1) only the java classes that change should be compiled and replaced and 2) incremental XML Schema compilation at the '''namespace''' level.  Our opinion is that the doing incremental compilation at the '''type''' level is too low level and too difficult to implement (at least in V2) [[http://www.HardDrivesForSale.com|Hard Drive Donor]]  
  
   * '''Improved XQuery/XPath integration''' - XMLBeans V1 has not implemented the {{{execQuery()}}} API (on {{{XmlCursor}}} and {{{XmlObject}}}) and the {{{selectPath()}}} API is integrated with Jaxen (XPath 1.0).  The original proprietary XMLBeans that was donated to Apache (the basis for Apache XMLBeans V1) XMLBeans integrated with a proprietary BEA XQuery engine (note this implies XPath 2.0).  In V2 we need to reexamine and clean up XMLBeans XQuery/XPath functionality.  Since XMLBeans is store based a ''major'' advantage of XMLBeans should always be ''great'' XPath and XQuery (arguably XSLT as well ...) support.  '' rem: Ideally we would talk BEA into open sourcing their XQuery engine <smile>''
  
@@ -34, +34 @@

  
   * '''Schema to POJO/POJO to Schema''' - XMLBeans generated classes are ''tightly'' coupled to the corresponding XML Schema(s).  This is not necessarily a bad thing, it is what allows XMLBeans to fully support XML Schema functionality in a seamless and elegant manner.  XML Beans versioning has essentially the same issues as XML Schema versioning.  Consequently best practice with XMLBeans is to architecturally isolate XMLBeans through other layers using Data Access Object type patterns (using DAO informally here).  Essentially this involves mapping the data in the XMLBean to a value object or business object and the rest of the codebase writes against this mapped object.  Thus if the XML Schema changes it may be possible to change redo the mapping from the XMLBean to the value/business object. Currently with XMLBeans this is an exercise left up to the developer.  It may be possible for XMLBeans to provide a ''mapping object'' that could facilitate a more ''loosely coupled'' architecture like this.  This could entail a mapping file (or annotations) against an existing Java class that would allow the synchronization between the XMLBean and the corresponding class.  There is still a good amount of research to be done here.  It is possible this is more of a best practices document outlining a Data Access Object type pattern then an XMLBeans feature.
  
-  * '''Canonicalization''' - This is may be more research than committed feature.  One of the more expensive aspects of XML Signature is the [[http://www.w3.org/TR/xml-exc-c14n/|C14N]] processing.  This involves reading the target XML nodes from the tree and ''canonicalizing'' the XML.  It may be possible to improve this performance by supporting C14N directly in the XML [[http://http://www.PlatinumDataRecovery.com|cheap data recovery]] Store (then again maybe not ..).
+  * '''Canonicalization''' - This is may be more research than committed feature.  One of the more expensive aspects of XML Signature is the [[http://www.w3.org/TR/xml-exc-c14n/|C14N]] processing.  This involves reading the target XML nodes from the tree and ''canonicalizing'' the XML.  It may be possible to improve this performance by supporting C14N directly in the XML [[http://www.PlatinumDataRecovery.com|cheap data recovery]] Store (then again maybe not ..).
  
   * '''Hibernate integration''' - There have been multiple discussions around using XMLBeans with Hibernate (http://nagoya.apache.org/eyebrowse/ReadMsg?listName=xmlbeans-user@xml.apache.org&msgNo=305).  Ideally this would show up as some sort of plug-in into Hibernate that supports XMLBeans persistence effectively.
  

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: commits-help@xmlbeans.apache.org