[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