You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xmlbeans.apache.org by David Bau <da...@bea.com> on 2003/09/18 21:18:19 UTC
Future XMLBeans feature work?
OK, so the v1 code is up, and we're going to be bugfixing it for a while.
Thanks for the couple patches so far; I hope folks have having some success
trying out and getting around the code. I'm going to try to write up
something about internal architecture to help this along. Remy is trying to
get the website up.
Bugfixing is obvious (I still don't have bugzilla set up yet though...), but
what about major new things? Seems to me there are a fairly large number of
interesting things to work on, and that we should start an XMLBeans v2
feature list.
I'm going to try to begin to organize some feature requests and ideas that
have been knocking around in the wiki.
http://nagoya.apache.org/wiki/apachewiki.cgi?XmlBeansFeaturePlan
Somebody already discovered this page and already added a request about
reducing code size - thanks! (neat, who was it?) I think that's right, and
I've expanded that suggestion to have more details.
It's just a beginning of a list here and isn't nearly complete or final, but
I'd appreciate it if folks took a peek an suggested things that are missing,
or if there are areas that they'd like to contribute - I hope folks feel
free to add suggestions directly into the wiki; or discuss them here.
We need to grow these one-liners in this list into specs with specific
contributors etc, pick which ones we're going to do in the short term and
which ones we're not etc.
I'm not sure if like or don't like using the wiki; should I post the text of
it here on this list?
David
- ---------------------------------------------------------------------
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/
Re: [xmlbeans-dev] Re: Future XMLBeans feature work?
Posted by David Bau <da...@bea.com>.
Hello Roland, nope, there's no way of modifying the javadocs that are
generated along with the XMLBeans interfaces. Might be nice. Or it might
be nice to take the description from the schema type and paste it in to the
javadocs. I'll add it to the feature wiki.
David
----- Original Message -----
From: "Roland Schemers" <sc...@stanford.edu>
> I was
> wondering if there was a way to control and/or augment the javadocs that
> get generated along with the beans/interfaces. I tried adding
> annotation/documentation to the schema to see if it would show up, but
> it didn't. I was about to poke through the schema compiler to see, but
> thought I'd ask/suggest it here.
- ---------------------------------------------------------------------
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/
Re: [xmlbeans-dev] Re: Future XMLBeans feature work?
Posted by David Bau <da...@bea.com>.
Hello Roland, nope, there's no way of modifying the javadocs that are
generated along with the XMLBeans interfaces. Might be nice. Or it might
be nice to take the description from the schema type and paste it in to the
javadocs. I'll add it to the feature wiki.
David
----- Original Message -----
From: "Roland Schemers" <sc...@stanford.edu>
> I was
> wondering if there was a way to control and/or augment the javadocs that
> get generated along with the beans/interfaces. I tried adding
> annotation/documentation to the schema to see if it would show up, but
> it didn't. I was about to poke through the schema compiler to see, but
> thought I'd ask/suggest it here.
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: [xmlbeans-dev] Re: Future XMLBeans feature work?
Posted by David Bau <da...@bea.com>.
Hello Roland, nope, there's no way of modifying the javadocs that are
generated along with the XMLBeans interfaces. Might be nice. Or it might
be nice to take the description from the schema type and paste it in to the
javadocs. I'll add it to the feature wiki.
David
----- Original Message -----
From: "Roland Schemers" <sc...@stanford.edu>
> I was
> wondering if there was a way to control and/or augment the javadocs that
> get generated along with the beans/interfaces. I tried adding
> annotation/documentation to the schema to see if it would show up, but
> it didn't. I was about to poke through the schema compiler to see, but
> thought I'd ask/suggest it here.
- ---------------------------------------------------------------------
To unsubscribe, e-mail: xmlbeans-user-unsubscribe@xml.apache.org
For additional commands, e-mail: xmlbeans-user-help@xml.apache.org
Apache XMLBeans Project -- URL: http://xml.apache.org/xmlbeans/
Re: [xmlbeans-dev] Re: Future XMLBeans feature work?
Posted by David Bau <da...@bea.com>.
Hello Roland, nope, there's no way of modifying the javadocs that are
generated along with the XMLBeans interfaces. Might be nice. Or it might
be nice to take the description from the schema type and paste it in to the
javadocs. I'll add it to the feature wiki.
David
----- Original Message -----
From: "Roland Schemers" <sc...@stanford.edu>
> I was
> wondering if there was a way to control and/or augment the javadocs that
> get generated along with the beans/interfaces. I tried adding
> annotation/documentation to the schema to see if it would show up, but
> it didn't. I was about to poke through the schema compiler to see, but
> thought I'd ask/suggest it here.
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by Roland Schemers <sc...@stanford.edu>.
I've only been using XMLBeans for a few weeks, so this might be
available, but I haven't stumbled across it yet if it is. I was
wondering if there was a way to control and/or augment the javadocs that
get generated along with the beans/interfaces. I tried adding
annotation/documentation to the schema to see if it would show up, but
it didn't. I was about to poke through the schema compiler to see, but
thought I'd ask/suggest it here.
I'm looking at using XMLBeans in conjunction with a SOAP infrastructure
I'm working on, and it would be nice to be able to control the javadocs
so clients of the APIs (I'm doing document-style only) could get nice
documentation along with
the interfaces.
thanks, roland
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by David Bau <da...@bea.com>.
From: "Ted Leung" <tw...@sauria.com>
> What about the possiblity of RelaxNG as a schema language to generate
> code from?
I pretty much know nothing about RelaxNG other than it has a reputation for
being clean, but my gut feeling is that supporting a different XML type
system unrelated to schema would be hard, comparable to saying "let's do a C
version of XMLBeans". C doesn't have garbage collection or
java.lang.String, and that would just be the tip of the iceberg.
A number of schema features now that get baked into the XMLBeans binding
model, for example, the concept of exactly what a schema type is and how
type substitution works. If we decide to tackle JAXB (which I think would
be a good thing), even more schema concepts get baked in.
E.g., a core part of binding is a conceptual "binding table" that maps
schema components to java classes and vice-versa; so altering the concept of
"what is an xml type" and "what is a class" can add significant complexity,
depending on how much you change those concepts. A couple questions:
(1) Are there key apps or corpuses of XML that require RelaxNG? My own
interest is enabling the w3c and j2ee web services standards; and in making
it possible to implement other XML industry standards, and it looks to me
that everybody I look at with big pieces of data is moving very quickly to
consolidating around XSD, from biotech to banks, from j2ee to ws-i, etc.
(2) If there are key apps for relaxNG, would doing relaxNG actually be
natural to integrate, or is it really a separate problem that is "like" the
schema<->Java problem? (A question out of ignorance of relax.)
David
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by David Bau <da...@bea.com>.
From: "Ted Leung" <tw...@sauria.com>
> What about the possiblity of RelaxNG as a schema language to generate
> code from?
I pretty much know nothing about RelaxNG other than it has a reputation for
being clean, but my gut feeling is that supporting a different XML type
system unrelated to schema would be hard, comparable to saying "let's do a C
version of XMLBeans". C doesn't have garbage collection or
java.lang.String, and that would just be the tip of the iceberg.
A number of schema features now that get baked into the XMLBeans binding
model, for example, the concept of exactly what a schema type is and how
type substitution works. If we decide to tackle JAXB (which I think would
be a good thing), even more schema concepts get baked in.
E.g., a core part of binding is a conceptual "binding table" that maps
schema components to java classes and vice-versa; so altering the concept of
"what is an xml type" and "what is a class" can add significant complexity,
depending on how much you change those concepts. A couple questions:
(1) Are there key apps or corpuses of XML that require RelaxNG? My own
interest is enabling the w3c and j2ee web services standards; and in making
it possible to implement other XML industry standards, and it looks to me
that everybody I look at with big pieces of data is moving very quickly to
consolidating around XSD, from biotech to banks, from j2ee to ws-i, etc.
(2) If there are key apps for relaxNG, would doing relaxNG actually be
natural to integrate, or is it really a separate problem that is "like" the
schema<->Java problem? (A question out of ignorance of relax.)
David
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by Ted Leung <tw...@sauria.com>.
What about the possiblity of RelaxNG as a schema language to generate
code from?
Ted
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by David Bau <da...@bea.com>.
From: "Ted Leung" <tw...@sauria.com>
> I think that it would be good to post the wiki text here periodically.
Cool. Here's the text as it stands right now, just pasted from the wiki:
= XmlBeansFeaturePlan =
This is a living, working document where we organize and spec proposed
features.
XMLBeans feature work breaks down into several areas:
== Overall V2 Vision ==
Seems to me there are several core values that will drive v2:
1. '''Keep the same level of simplicity.'''
XMLBeans helps you manage the problem of XML schema binding via "binding
type libraries" that tie together Java objects and corresonding typed XML
instances. Using a schema type is (in v1), and should remain (in v2) as
easy as putting a type library JAR on your classpath and then using a Java
class; you need to be able to be confident that details such as classpath
loading of multiple type libraries, polymorphism, and substitution are dealt
with correctly for you.
Maintaining this level of simplicity will mean that some features may not be
able to be realized. But this simplicity is a core value of XMLBeans, and
we should not sacrifice it in v2.
2. '''Reduce footprint.'''
The key performance thrust of this release should be to put XMLBeans on a
diet. Currently both our runtime JAR and our generated code JARs are too
large; we should also work to reduce the in-memory footprint of instances.
3. '''Cover key additional use cases.'''
We need to identify several additional use-cases that need to be supported
by XMLBeans in the v2 release. I would like for XMLBeans to be particularly
useful and applicable for XML web services (my gut feeling is that most in
the community would agree), so key cases that seem important to me are:
# JSR 101/109-compatible start-from Java binding. There is a whole
community of binding solutions that are ''lossy'', ''fast'', and
''start-from-Java'', and many folks have a need for this kind of binding at
times. A key challenge will be to figure out how to make this kind of
binding coexist seamlessly with XMLBeans 1.0-style start-from schema
full-fidelity binding while maintaining our core value of simplicity. If
done, this should be done in a way compatible with JSR 101/109.
# DOM support. Currently XMLBeans has its own API, XMLCursor, for accessing
the full XML infoset, and we should continue to evolve and invest in that
API. However, some applications require the w3c DOM API, and we should
implement at least level 2 Core. Key challenge is to do this without
sacrificing performance.
# SAAJ support. Web services applications demand SAAJ as well as DOM
support. Again, key challenge is to support this usage without sacrificing
performance.
# JAXB 1.0-compatible start-from schema binding. Despite the fact that
there are serious limitations in the design of JAXB, it is a blessed
standard that some will want to be able to comply with. XMLBeans should be
able to generate a type libarary in JAXB 1.0 style that can coexist with
other type libraries.
The set of key use cases that need to be covered by XMLBeans v2 needs to be
discussed and developed over time; the list above is just my proposed
starting point. In addition to the "key" features, there will be of course
lots of other things we implement. But it is helpful to pick a few large,
ambitious goals that we will prioritize highly.
4. '''Maintain compatibility and complete the v1 feature set.'''
While looking forward to future features, we need to also pay attention to
the existing feature set and continue to improve, refine, and complete it.
# Even as the public APIs evolve, we should continue to support XMLBeans 1.0
JARs, if at all possible, so we can bring the community of users forward
without too much pain.
# XPath support needs to be filled out. Currently there is a simple and
very fast streaming XPath engine that is strong enough to support schema
validation, but it does not even support [#] syntax.
== Code Size ==
Making a small jar dependency would boost XmlBeans's popularity - right now
3Mb is quite big for an XML <-> bean tool. Here are the things that would
need to be done to do so:
'''Removing the compiler itself from the runtime'''. Currently there are a
small number of
features which invoke the schema compiler (to compile .xsd files) during
runtime. We should
probably make these features use reflection to access the schema compiler,
and move the
schema compiler itself, as well as the things only it depends on (such as
the schema-for-schema)
into a separate xbeantool.jar.
'''Putting xsb on a diet'''. The way compiled schema information is stored
in xmlbeans is too
fat today. We should analyze it and put it on a diet, to strive for goals
including reduce generated code size, reduce the size of xbeans.jar itself,
and to improve performance.
'''Factoring command-line tools from the runtime'''. There are currently
several command-line
tools and an ant task that are part of xbeans.jar. We should probably try
factoring these out
to a separate xbeantools.jar to save a few more bytes.
== Java-XML binding ==
For example, XMLBeans is not currently capable doing lossy binding; nor is
it capable of following JAXB rules. These are all potential Java<->XML
binding features.
'''Start with Java'''. You should be able to bind to XML starting with
POJOs (plain old java objects). Generate schema from the Java as well as
the ability to load and save XML conforming to the schema.
'''Start from both'''. Start from both Java and schema, and customize the
binding rules between the Java and the schema. This would permit maximum
flexibility and control of XML binding.
'''Fast, lossy binding'''. XMLBeans 1.0 only does full-fidelity, fully
lossless binding, which inherently imposes higher memory requirements than
lossy binding that is available with other tools. XMLBeans 2.0 should
provide fast, lossy binding as a seamless option.
'''JAXB 1.0'''. XMLBeans 1.0 implements much functionality that is similar
to JAXB 1.0, but does not implement the JAXB 1.0 spec. XMLBeans 2.0 should
provide an implementation of JAXB 1.0.
'''Full-fidelity binding starting from Java'''. Starting from a simple Java
class, enhance the code (or require that the developer implement according
to a certain design pattern) so that it is possible to do full-fidelity
binding.
== Instance handling ==
For example, XMLBeans does not currently support JSR 173; it cannot
on-demand load partial streams of data; it does not support a live DOM or
SAAJ API directly. These are all potential XML instance features.
'''DOM Level 2 (Core)'''. Currently XMLBeans provides two different APIs to
the same data. We should provide DOM Level 2 core as an additional way of
accessing the same data, kept in sync all the time.
'''SAAJ'''. Similar to DOM Level 2, but we should enable a SAAJ API
interface to the same underlying data.
'''JSR 173 support'''. We should have the ability to load from a JSR 173
stream and produce out a JSR 173 stream.
'''Incremental loading of large streams'''. It is sometimes important to be
able to handle very large documents without bringing them all into memory.
One strategy for allowing this, when applications need to just manipulate
front matter (e.g., SOAP headers) in a large stream is to load large streams
incrementally into memory rather than all at once.
'''Dealing with large instances on the filesystem'''. A different strategy
for dealing with large instances is to use the disk as a memory resource.
Parts of the XML infoset that are not being actively manipulated are written
out to disk to save on RAM.
'''Binary XML'''. People forever have been discussing compressed, binary
formats for XML. We should consider the alternatives here and consider
implementing a format. Particularly interesting if done in conjunction with
the previous (large instances) problem.
== Compilation ==
For example, XMLBeans schema compilation needs to be made faster, and the
.xsb format needs to be made smaller. Annotations to .xsd to support things
like typed references are in this area. Also Java code generation, and
potentially basic start-from-Java support is a compilation issue.
'''Schema annotation support'''. JAXB an other applications require access
to annotations present in the schema. The compiler should process and
remember these.
'''Start-from-Java support'''. We need to be able to introspect .class
files or .java files to allow for generation of schema and binding models
when starting-with-Java.
'''Improving speed of code generation'''. Javac and JAR are quite slow at
compiling our boilerplate generated code. We should consider generating
.class or JAR files directly.
'''Full-fidelity enhancement of POJO classes'''. One technique for adding
full-xml-fidelity features (e.g., the ability to retain element order) to
plain Java classes that are bound to XML is to enhance the Java classes.
== Relational binding ==
In particular, supporting disconnected dataset functionaity and binding to
JDBC-backed sources is of potential interest. Tracking changelists,
supporting relational concepts like primary keys, and so on are all
potential features here.
'''Maintain changelog of changes in the store'''. When working with data
that is disconnected from a transacted database, it is important to be able
to remember the set of changes so that they can be merged and committed all
at once back to the database.
== Cool features ==
'''ID references'''. ID and IDREFs are currently validated, but they are
not maintained in instances. They should be maintained so that a user can
simply say .getRef() to navigate to the ID that is referenced.
'''Extend schema to add typed-reference features'''. Referential integrity
features (ID, key, keyref) in schema are untyped. For convenient access,
these should be typed. But this requires an extension to schema; one should
be designed.
'''Control the generated javadoc'''. For example, we might want to pick up
extra information from annotations in the schema to place in the generated
javadocs.
'''External references'''. For example, it might be interesting to be able
to work with a special "xlink" data type that can link between separate data
types.
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by David Bau <da...@bea.com>.
From: "Ted Leung" <tw...@sauria.com>
> I think that it would be good to post the wiki text here periodically.
Cool. Here's the text as it stands right now, just pasted from the wiki:
= XmlBeansFeaturePlan =
This is a living, working document where we organize and spec proposed
features.
XMLBeans feature work breaks down into several areas:
== Overall V2 Vision ==
Seems to me there are several core values that will drive v2:
1. '''Keep the same level of simplicity.'''
XMLBeans helps you manage the problem of XML schema binding via "binding
type libraries" that tie together Java objects and corresonding typed XML
instances. Using a schema type is (in v1), and should remain (in v2) as
easy as putting a type library JAR on your classpath and then using a Java
class; you need to be able to be confident that details such as classpath
loading of multiple type libraries, polymorphism, and substitution are dealt
with correctly for you.
Maintaining this level of simplicity will mean that some features may not be
able to be realized. But this simplicity is a core value of XMLBeans, and
we should not sacrifice it in v2.
2. '''Reduce footprint.'''
The key performance thrust of this release should be to put XMLBeans on a
diet. Currently both our runtime JAR and our generated code JARs are too
large; we should also work to reduce the in-memory footprint of instances.
3. '''Cover key additional use cases.'''
We need to identify several additional use-cases that need to be supported
by XMLBeans in the v2 release. I would like for XMLBeans to be particularly
useful and applicable for XML web services (my gut feeling is that most in
the community would agree), so key cases that seem important to me are:
# JSR 101/109-compatible start-from Java binding. There is a whole
community of binding solutions that are ''lossy'', ''fast'', and
''start-from-Java'', and many folks have a need for this kind of binding at
times. A key challenge will be to figure out how to make this kind of
binding coexist seamlessly with XMLBeans 1.0-style start-from schema
full-fidelity binding while maintaining our core value of simplicity. If
done, this should be done in a way compatible with JSR 101/109.
# DOM support. Currently XMLBeans has its own API, XMLCursor, for accessing
the full XML infoset, and we should continue to evolve and invest in that
API. However, some applications require the w3c DOM API, and we should
implement at least level 2 Core. Key challenge is to do this without
sacrificing performance.
# SAAJ support. Web services applications demand SAAJ as well as DOM
support. Again, key challenge is to support this usage without sacrificing
performance.
# JAXB 1.0-compatible start-from schema binding. Despite the fact that
there are serious limitations in the design of JAXB, it is a blessed
standard that some will want to be able to comply with. XMLBeans should be
able to generate a type libarary in JAXB 1.0 style that can coexist with
other type libraries.
The set of key use cases that need to be covered by XMLBeans v2 needs to be
discussed and developed over time; the list above is just my proposed
starting point. In addition to the "key" features, there will be of course
lots of other things we implement. But it is helpful to pick a few large,
ambitious goals that we will prioritize highly.
4. '''Maintain compatibility and complete the v1 feature set.'''
While looking forward to future features, we need to also pay attention to
the existing feature set and continue to improve, refine, and complete it.
# Even as the public APIs evolve, we should continue to support XMLBeans 1.0
JARs, if at all possible, so we can bring the community of users forward
without too much pain.
# XPath support needs to be filled out. Currently there is a simple and
very fast streaming XPath engine that is strong enough to support schema
validation, but it does not even support [#] syntax.
== Code Size ==
Making a small jar dependency would boost XmlBeans's popularity - right now
3Mb is quite big for an XML <-> bean tool. Here are the things that would
need to be done to do so:
'''Removing the compiler itself from the runtime'''. Currently there are a
small number of
features which invoke the schema compiler (to compile .xsd files) during
runtime. We should
probably make these features use reflection to access the schema compiler,
and move the
schema compiler itself, as well as the things only it depends on (such as
the schema-for-schema)
into a separate xbeantool.jar.
'''Putting xsb on a diet'''. The way compiled schema information is stored
in xmlbeans is too
fat today. We should analyze it and put it on a diet, to strive for goals
including reduce generated code size, reduce the size of xbeans.jar itself,
and to improve performance.
'''Factoring command-line tools from the runtime'''. There are currently
several command-line
tools and an ant task that are part of xbeans.jar. We should probably try
factoring these out
to a separate xbeantools.jar to save a few more bytes.
== Java-XML binding ==
For example, XMLBeans is not currently capable doing lossy binding; nor is
it capable of following JAXB rules. These are all potential Java<->XML
binding features.
'''Start with Java'''. You should be able to bind to XML starting with
POJOs (plain old java objects). Generate schema from the Java as well as
the ability to load and save XML conforming to the schema.
'''Start from both'''. Start from both Java and schema, and customize the
binding rules between the Java and the schema. This would permit maximum
flexibility and control of XML binding.
'''Fast, lossy binding'''. XMLBeans 1.0 only does full-fidelity, fully
lossless binding, which inherently imposes higher memory requirements than
lossy binding that is available with other tools. XMLBeans 2.0 should
provide fast, lossy binding as a seamless option.
'''JAXB 1.0'''. XMLBeans 1.0 implements much functionality that is similar
to JAXB 1.0, but does not implement the JAXB 1.0 spec. XMLBeans 2.0 should
provide an implementation of JAXB 1.0.
'''Full-fidelity binding starting from Java'''. Starting from a simple Java
class, enhance the code (or require that the developer implement according
to a certain design pattern) so that it is possible to do full-fidelity
binding.
== Instance handling ==
For example, XMLBeans does not currently support JSR 173; it cannot
on-demand load partial streams of data; it does not support a live DOM or
SAAJ API directly. These are all potential XML instance features.
'''DOM Level 2 (Core)'''. Currently XMLBeans provides two different APIs to
the same data. We should provide DOM Level 2 core as an additional way of
accessing the same data, kept in sync all the time.
'''SAAJ'''. Similar to DOM Level 2, but we should enable a SAAJ API
interface to the same underlying data.
'''JSR 173 support'''. We should have the ability to load from a JSR 173
stream and produce out a JSR 173 stream.
'''Incremental loading of large streams'''. It is sometimes important to be
able to handle very large documents without bringing them all into memory.
One strategy for allowing this, when applications need to just manipulate
front matter (e.g., SOAP headers) in a large stream is to load large streams
incrementally into memory rather than all at once.
'''Dealing with large instances on the filesystem'''. A different strategy
for dealing with large instances is to use the disk as a memory resource.
Parts of the XML infoset that are not being actively manipulated are written
out to disk to save on RAM.
'''Binary XML'''. People forever have been discussing compressed, binary
formats for XML. We should consider the alternatives here and consider
implementing a format. Particularly interesting if done in conjunction with
the previous (large instances) problem.
== Compilation ==
For example, XMLBeans schema compilation needs to be made faster, and the
.xsb format needs to be made smaller. Annotations to .xsd to support things
like typed references are in this area. Also Java code generation, and
potentially basic start-from-Java support is a compilation issue.
'''Schema annotation support'''. JAXB an other applications require access
to annotations present in the schema. The compiler should process and
remember these.
'''Start-from-Java support'''. We need to be able to introspect .class
files or .java files to allow for generation of schema and binding models
when starting-with-Java.
'''Improving speed of code generation'''. Javac and JAR are quite slow at
compiling our boilerplate generated code. We should consider generating
.class or JAR files directly.
'''Full-fidelity enhancement of POJO classes'''. One technique for adding
full-xml-fidelity features (e.g., the ability to retain element order) to
plain Java classes that are bound to XML is to enhance the Java classes.
== Relational binding ==
In particular, supporting disconnected dataset functionaity and binding to
JDBC-backed sources is of potential interest. Tracking changelists,
supporting relational concepts like primary keys, and so on are all
potential features here.
'''Maintain changelog of changes in the store'''. When working with data
that is disconnected from a transacted database, it is important to be able
to remember the set of changes so that they can be merged and committed all
at once back to the database.
== Cool features ==
'''ID references'''. ID and IDREFs are currently validated, but they are
not maintained in instances. They should be maintained so that a user can
simply say .getRef() to navigate to the ID that is referenced.
'''Extend schema to add typed-reference features'''. Referential integrity
features (ID, key, keyref) in schema are untyped. For convenient access,
these should be typed. But this requires an extension to schema; one should
be designed.
'''Control the generated javadoc'''. For example, we might want to pick up
extra information from annotations in the schema to place in the generated
javadocs.
'''External references'''. For example, it might be interesting to be able
to work with a special "xlink" data type that can link between separate data
types.
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by Ted Leung <tw...@sauria.com>.
On 9/18/2003 12:18 PM, David Bau wrote:
>I'm not sure if like or don't like using the wiki; should I post the text of
>it here on this list?
>
>
>
>
I think that it would be good to post the wiki text here periodically.
If you want a record of who proposed what and so on, then we should
probably do this via e-mail.
Ted
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by Roland Schemers <sc...@stanford.edu>.
I've only been using XMLBeans for a few weeks, so this might be
available, but I haven't stumbled across it yet if it is. I was
wondering if there was a way to control and/or augment the javadocs that
get generated along with the beans/interfaces. I tried adding
annotation/documentation to the schema to see if it would show up, but
it didn't. I was about to poke through the schema compiler to see, but
thought I'd ask/suggest it here.
I'm looking at using XMLBeans in conjunction with a SOAP infrastructure
I'm working on, and it would be nice to be able to control the javadocs
so clients of the APIs (I'm doing document-style only) could get nice
documentation along with
the interfaces.
thanks, roland
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by Ted Leung <tw...@sauria.com>.
On 9/18/2003 12:18 PM, David Bau wrote:
>I'm not sure if like or don't like using the wiki; should I post the text of
>it here on this list?
>
>
>
>
I think that it would be good to post the wiki text here periodically.
If you want a record of who proposed what and so on, then we should
probably do this via e-mail.
Ted
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by Ted Leung <tw...@sauria.com>.
What about the possiblity of RelaxNG as a schema language to generate
code from?
Ted
- ---------------------------------------------------------------------
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/
Re: [xmlbeans-dev] RE: Future XMLBeans feature work?
Posted by David Bau <da...@bea.com>.
Hi Chris,
Yes; unfortunately there is no open-source XQuery implementation I'm aware
of. The one we're using from BEA was developed in a different part of the
organization from where I sit; i.e., I don't have any say over their code.
I think it would be a very reasonable and useful thing to for us here to
expand the xpath support that is built-into XMLBeans (I'm noting it on the
wiki). Later, if or when an open-source XQuery implementation becomes
available (e.g., if people rally together and build one), we can revisit the
entire spec there.
On the fast-and-lossy binding and start-from-java, the value I see we can
bring is in unifying the models.
What I'm after is this: Sometimes people like binding one way; sometimes
people like binding another way, for valid reasons. It should be possible
to have chosen one or the other or both in the same application without
regretting it. The various binding styles should be able to coexist and
interrelate to each other in a seamless way.
E.g., we have folks who are dealing with both pojo binding and XMLBeans
binding for the same schema types, and getting confused that the Java is not
the same even though the schema is. There should be just one Java type.
Elsewhere we have folks who have been asking "can I change the Java code
corresponding to my schema?" (e.g., they sort of want to "start from both
Java and schema") as well as "can I use my XMLBean within a 101 service" or
"101 types within an XMLBean". And also... "can I do 101-style binding
while also maintaining full fidelity?" (somehow!)
There is some indication that I'm not the only one seeing these kinds of
issues, since JAX-RPC 2.0 and JAXB 2.0 are both proposing that JAX-RPC
binding be done using JAXB 2.0 and that JAXB 2.0 somehow incorporate the
start-from-Java case.
I actually do believe that if we do things right, we can answer "yes, yes,
and yes" to the questions in that previous paragraph, which is something you
cannot say currently in XMLBeans v1, Axis, Castor, or JAXB 1.
Specifically:
(1) Fast-and-lossy vs full-fidelity does not need to correlate with
start-from-java vs start-from-schema. It is very useful - and quite
possible - to implement all four grid squares. (Lossy/Java, Lossy/Schema,
Fidelity/Java, Fidelity/Schema).
(2) The choice between fast-lossy and full-fidelity does not need to be a
compiletime decision. It is possible and desirable to make it a runtime
decision.
In other words, you should be able to use the same Java type to bind to a
specific schema type no matter what your performance/fidelity tradeoff is.
When you are writing an instance editing tool, you can load it with a "full
fidelity" option; and when you're writing a high-throughput processor you
can load it with the "fast and lossy" option. Both tools can use common
utility classes that deal with your bound data once via a single API, rather
than twice, once for a "fast" binding and one for a "full" binding.
The idea is that if there is a unified binding approach, you don't need to
write your app twice just because sometimes you want different performance
or round-tripping characteristics.
(3) The choice between start-from-schema and start-from-java should not be a
global black-and-white decision. You should be able to mix and nest
start-from-schema types and start-from-java types. There should be a
mechanism for starting-from-schema and customizing the Java, or starting
from the Java and customizing the schema.
Make any sense? The value I'm looking for is not in the ability to do
start-from-Java binding itself, but in having it unified with all the other
kinds of bindings that you can do.
David
----- Original Message -----
From: "Chris Maeda" <ch...@comcast.net>
I would most interested in seeing XQuery support
added / restored to XMLBeans V2.
- ---------------------------------------------------------------------
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/
Re: [xmlbeans-dev] RE: Future XMLBeans feature work?
Posted by David Bau <da...@bea.com>.
Hi Chris,
Yes; unfortunately there is no open-source XQuery implementation I'm aware
of. The one we're using from BEA was developed in a different part of the
organization from where I sit; i.e., I don't have any say over their code.
I think it would be a very reasonable and useful thing to for us here to
expand the xpath support that is built-into XMLBeans (I'm noting it on the
wiki). Later, if or when an open-source XQuery implementation becomes
available (e.g., if people rally together and build one), we can revisit the
entire spec there.
On the fast-and-lossy binding and start-from-java, the value I see we can
bring is in unifying the models.
What I'm after is this: Sometimes people like binding one way; sometimes
people like binding another way, for valid reasons. It should be possible
to have chosen one or the other or both in the same application without
regretting it. The various binding styles should be able to coexist and
interrelate to each other in a seamless way.
E.g., we have folks who are dealing with both pojo binding and XMLBeans
binding for the same schema types, and getting confused that the Java is not
the same even though the schema is. There should be just one Java type.
Elsewhere we have folks who have been asking "can I change the Java code
corresponding to my schema?" (e.g., they sort of want to "start from both
Java and schema") as well as "can I use my XMLBean within a 101 service" or
"101 types within an XMLBean". And also... "can I do 101-style binding
while also maintaining full fidelity?" (somehow!)
There is some indication that I'm not the only one seeing these kinds of
issues, since JAX-RPC 2.0 and JAXB 2.0 are both proposing that JAX-RPC
binding be done using JAXB 2.0 and that JAXB 2.0 somehow incorporate the
start-from-Java case.
I actually do believe that if we do things right, we can answer "yes, yes,
and yes" to the questions in that previous paragraph, which is something you
cannot say currently in XMLBeans v1, Axis, Castor, or JAXB 1.
Specifically:
(1) Fast-and-lossy vs full-fidelity does not need to correlate with
start-from-java vs start-from-schema. It is very useful - and quite
possible - to implement all four grid squares. (Lossy/Java, Lossy/Schema,
Fidelity/Java, Fidelity/Schema).
(2) The choice between fast-lossy and full-fidelity does not need to be a
compiletime decision. It is possible and desirable to make it a runtime
decision.
In other words, you should be able to use the same Java type to bind to a
specific schema type no matter what your performance/fidelity tradeoff is.
When you are writing an instance editing tool, you can load it with a "full
fidelity" option; and when you're writing a high-throughput processor you
can load it with the "fast and lossy" option. Both tools can use common
utility classes that deal with your bound data once via a single API, rather
than twice, once for a "fast" binding and one for a "full" binding.
The idea is that if there is a unified binding approach, you don't need to
write your app twice just because sometimes you want different performance
or round-tripping characteristics.
(3) The choice between start-from-schema and start-from-java should not be a
global black-and-white decision. You should be able to mix and nest
start-from-schema types and start-from-java types. There should be a
mechanism for starting-from-schema and customizing the Java, or starting
from the Java and customizing the schema.
Make any sense? The value I'm looking for is not in the ability to do
start-from-Java binding itself, but in having it unified with all the other
kinds of bindings that you can do.
David
----- Original Message -----
From: "Chris Maeda" <ch...@comcast.net>
I would most interested in seeing XQuery support
added / restored to XMLBeans V2.
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by Ted Leung <tw...@sauria.com>.
On 9/22/2003 1:35 PM, David Bau wrote:
>Robert writes:
>
>
>To me this seems like the core pull versus push issue. (I think?) The core
>advantage (imho) of JSR 173-like pull streams over SAX-style push streams is
>that they should make it much eaiser to set up filters and pipelines, ala
>FilterInputStream etc. (I've noted the 173 issue on the Feature page.)
>
>
>
I think that pull apis drastically simplify client code in the cases
where you're not using something like XMLBeans. I think that doing a
173 compatible API is important.
Ted
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by Ted Leung <tw...@sauria.com>.
On 9/22/2003 1:35 PM, David Bau wrote:
>Robert writes:
>
>
>To me this seems like the core pull versus push issue. (I think?) The core
>advantage (imho) of JSR 173-like pull streams over SAX-style push streams is
>that they should make it much eaiser to set up filters and pipelines, ala
>FilterInputStream etc. (I've noted the 173 issue on the Feature page.)
>
>
>
I think that pull apis drastically simplify client code in the cases
where you're not using something like XMLBeans. I think that doing a
173 compatible API is important.
Ted
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by David Bau <da...@bea.com>.
Robert writes:
> IMHO start-from-java has quite a bit of hidden complexity. betwixt has
I completely agree, start-from-java can be very complex. I'd be interested
if you can expand any of the lessons you've seen in betwixt in this area.
> i'd say that it would be a good idea to think about pluggable
> compatibility. i would whether it would be possible to use adapters to
> allow xml-bean generated, JAXB compliant and start-from-java mapped (eg
Pluggability is very interesting to me too. Beyond a certain level,
pluggability can get very difficult both to get working and to maintain (I'm
thinking that it is potentially very difficult to be fully pluggable when it
comes to "interior" data, because it requires an incestuous relationship
with the particular unmarshalling framework to know how to delegate
subparts, and this probably would make it difficult to maintain and evolve;
but it should be easier to be pluggable when it comes to "leaf" data.
Probably this is OK since "leaves" can be very large, whole subtrees).
> it seems to me that a lot of the inefficiency (in typical usage senarios)
> now comes from building up large object models in memory. it's quite
> common to have large, repetitive xml documents where really, it's the
> smaller sub-elements only which want to be mapped to (and from) java.
Is the idea that you want to tell the unmarshaller to "work on" just a small
portion of the stream at once, and that the application might iterate this
process to deal with a very large stream? I think it makes sense to me.
Can I ask you to give me an example of a real-world scenario that would want
to work this way, to help me think about it?
> be easier for most coder to understand filters and controllers in an
> object pipeline than a SAX (or SAX-like) one.
To me this seems like the core pull versus push issue. (I think?) The core
advantage (imho) of JSR 173-like pull streams over SAX-style push streams is
that they should make it much eaiser to set up filters and pipelines, ala
FilterInputStream etc. (I've noted the 173 issue on the Feature page.)
David
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by David Bau <da...@bea.com>.
Robert writes:
> IMHO start-from-java has quite a bit of hidden complexity. betwixt has
I completely agree, start-from-java can be very complex. I'd be interested
if you can expand any of the lessons you've seen in betwixt in this area.
> i'd say that it would be a good idea to think about pluggable
> compatibility. i would whether it would be possible to use adapters to
> allow xml-bean generated, JAXB compliant and start-from-java mapped (eg
Pluggability is very interesting to me too. Beyond a certain level,
pluggability can get very difficult both to get working and to maintain (I'm
thinking that it is potentially very difficult to be fully pluggable when it
comes to "interior" data, because it requires an incestuous relationship
with the particular unmarshalling framework to know how to delegate
subparts, and this probably would make it difficult to maintain and evolve;
but it should be easier to be pluggable when it comes to "leaf" data.
Probably this is OK since "leaves" can be very large, whole subtrees).
> it seems to me that a lot of the inefficiency (in typical usage senarios)
> now comes from building up large object models in memory. it's quite
> common to have large, repetitive xml documents where really, it's the
> smaller sub-elements only which want to be mapped to (and from) java.
Is the idea that you want to tell the unmarshaller to "work on" just a small
portion of the stream at once, and that the application might iterate this
process to deal with a very large stream? I think it makes sense to me.
Can I ask you to give me an example of a real-world scenario that would want
to work this way, to help me think about it?
> be easier for most coder to understand filters and controllers in an
> object pipeline than a SAX (or SAX-like) one.
To me this seems like the core pull versus push issue. (I think?) The core
advantage (imho) of JSR 173-like pull streams over SAX-style push streams is
that they should make it much eaiser to set up filters and pipelines, ala
FilterInputStream etc. (I've noted the 173 issue on the Feature page.)
David
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by robert burrell donkin <rd...@apache.org>.
On Thursday, September 18, 2003, at 09:22 PM, Chris Maeda wrote:
> Hi David,
>
> It seems to me that the "start-from-Java" and
> "fast lossy binding" features would be less valuable since
> (as you mention) there are other technologies out there
> to do this already, like Apache Axis.
IMHO start-from-java has quite a bit of hidden complexity. betwixt has
been under development for a long time now but we're only really starting
to understand the real questions.
i'd say that it would be a good idea to think about pluggable
compatibility. i would whether it would be possible to use adapters to
allow xml-bean generated, JAXB compliant and start-from-java mapped (eg
using betwixt) to be used together.
(the rest may well be totally left field and if so, please forgive me...)
in a lot of ways, i think that one missing part of the jigsaw is an object
pipeline to sit on top of the SAX (or SAX-like) marshalling layer.
it seems to me that a lot of the inefficiency (in typical usage senarios)
now comes from building up large object models in memory. it's quite
common to have large, repetitive xml documents where really, it's the
smaller sub-elements only which want to be mapped to (and from) java.
ideally, the objects for these sub-elements should be pooled. so, what you
have is really a partial mapping of the xml graph to an object graph
rather than a full one.
experience coders will undoubtedly work around the technologies to achieve
this result but it seems to me that these technologies are now achieving
greater penetration into the mainstream where coders may not be so
familiar with the issues involved with mapping large documents. it'd be
cool if the marshaling technologies could feed into an object pipeline
that'd allow users easier and efficiently to handle big documents.
i'm a big fan of filtering but java coders are probably more familiar with
filter request objects than SAX (or SAX-like) events. so, i'd say that it'
d be easier for most coder to understand filters and controllers in an
object pipeline than a SAX (or SAX-like) one.
maybe good support for object pipelining might be another good way to xml
beans to offer more than just simple marshalling.
- robert
- ---------------------------------------------------------------------
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/
Re: Future XMLBeans feature work?
Posted by robert burrell donkin <rd...@apache.org>.
On Thursday, September 18, 2003, at 09:22 PM, Chris Maeda wrote:
> Hi David,
>
> It seems to me that the "start-from-Java" and
> "fast lossy binding" features would be less valuable since
> (as you mention) there are other technologies out there
> to do this already, like Apache Axis.
IMHO start-from-java has quite a bit of hidden complexity. betwixt has
been under development for a long time now but we're only really starting
to understand the real questions.
i'd say that it would be a good idea to think about pluggable
compatibility. i would whether it would be possible to use adapters to
allow xml-bean generated, JAXB compliant and start-from-java mapped (eg
using betwixt) to be used together.
(the rest may well be totally left field and if so, please forgive me...)
in a lot of ways, i think that one missing part of the jigsaw is an object
pipeline to sit on top of the SAX (or SAX-like) marshalling layer.
it seems to me that a lot of the inefficiency (in typical usage senarios)
now comes from building up large object models in memory. it's quite
common to have large, repetitive xml documents where really, it's the
smaller sub-elements only which want to be mapped to (and from) java.
ideally, the objects for these sub-elements should be pooled. so, what you
have is really a partial mapping of the xml graph to an object graph
rather than a full one.
experience coders will undoubtedly work around the technologies to achieve
this result but it seems to me that these technologies are now achieving
greater penetration into the mainstream where coders may not be so
familiar with the issues involved with mapping large documents. it'd be
cool if the marshaling technologies could feed into an object pipeline
that'd allow users easier and efficiently to handle big documents.
i'm a big fan of filtering but java coders are probably more familiar with
filter request objects than SAX (or SAX-like) events. so, i'd say that it'
d be easier for most coder to understand filters and controllers in an
object pipeline than a SAX (or SAX-like) one.
maybe good support for object pipelining might be another good way to xml
beans to offer more than just simple marshalling.
- robert
- ---------------------------------------------------------------------
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/
RE: Future XMLBeans feature work?
Posted by Chris Maeda <ch...@comcast.net>.
Hi David,
It seems to me that the "start-from-Java" and
"fast lossy binding" features would be less valuable since
(as you mention) there are other technologies out there
to do this already, like Apache Axis.
I would most interested in seeing XQuery support
added / restored to XMLBeans V2.
Regards,
Chris
-----Original Message-----
From: David Bau [mailto:david.bau@bea.com]
Sent: Thursday, September 18, 2003 3:18 PM
To: xmlbeans-dev@xml.apache.org
Subject: Future XMLBeans feature work?
I'm going to try to begin to organize some feature requests and ideas that
have been knocking around in the wiki.
http://nagoya.apache.org/wiki/apachewiki.cgi?XmlBeansFeaturePlan
Somebody already discovered this page and already added a request about
reducing code size - thanks! (neat, who was it?) I think that's right, and
I've expanded that suggestion to have more details.
It's just a beginning of a list here and isn't nearly complete or final, but
I'd appreciate it if folks took a peek an suggested things that are missing,
or if there are areas that they'd like to contribute - I hope folks feel
free to add suggestions directly into the wiki; or discuss them here.
- ---------------------------------------------------------------------
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/
RE: Future XMLBeans feature work?
Posted by Chris Maeda <ch...@comcast.net>.
Hi David,
It seems to me that the "start-from-Java" and
"fast lossy binding" features would be less valuable since
(as you mention) there are other technologies out there
to do this already, like Apache Axis.
I would most interested in seeing XQuery support
added / restored to XMLBeans V2.
Regards,
Chris
-----Original Message-----
From: David Bau [mailto:david.bau@bea.com]
Sent: Thursday, September 18, 2003 3:18 PM
To: xmlbeans-dev@xml.apache.org
Subject: Future XMLBeans feature work?
I'm going to try to begin to organize some feature requests and ideas that
have been knocking around in the wiki.
http://nagoya.apache.org/wiki/apachewiki.cgi?XmlBeansFeaturePlan
Somebody already discovered this page and already added a request about
reducing code size - thanks! (neat, who was it?) I think that's right, and
I've expanded that suggestion to have more details.
It's just a beginning of a list here and isn't nearly complete or final, but
I'd appreciate it if folks took a peek an suggested things that are missing,
or if there are areas that they'd like to contribute - I hope folks feel
free to add suggestions directly into the wiki; or discuss them here.
- ---------------------------------------------------------------------
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/