[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    the store and binding [Re: default constructors
From:       Aleksander Slominski <aslom () cs ! indiana ! edu>
Date:       2004-04-30 23:38:21
Message-ID: 4092E36D.6000105 () cs ! indiana ! edu
[Download RAW message or body]

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/

[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic