the store and binding [Re: default constructors

[Aleksander Slominski <as...@cs.indiana.edu>]

David Remy wrote:

>that being said i think, given the foundation that has been built, we can attack the more
>constrained use cases within the xmlbeans binding itself (as opposed to spawning another binding
>from the SOM).  for example, it is possible to imagine an 'infoset lossy' setting at codegen 
>time that would generate a java class based implementation of the XMLObject interface in the 
>generated classes.  Factory.parse() would directly populate java objects (hence parts of XML
>Infoset would not be available), calls to APIs that give direct access to the xml store, like
>newCursor(), would get an UnsupportedOperationException.  The key here is that a user should be 
>able to flip that codegen/compilation switch at any point if they determine they need access
>to more of the underlying XML Infoset and not break any of their existing code.
>
>  
>
hi,

what about non-lossy but an alternative to the store XML Infoset 
representation.

for example one could consider DOM as the backing store or XML database 
(as Gerald described).

>Sorry for such a long post on this, just started dumping ...
>  
>
very interesting core dump :)

alek

-- 
The best way to predict the future is to invent it - Alan Kay


- ---------------------------------------------------------------------
To unsubscribe, e-mail:   xmlbeans-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-dev-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/