You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlbeans-user@xml.apache.org by David Remy <dr...@bea.com> on 2004/05/28 21:53:11 UTC
EWorld ...
I spoke on Tues at EWorld about XMLBeans. I did a session called
"Advanced XMLBeans" which was great because everyone that walked in sort
of pre-qualified themselves just because they were willing to attend a
talk with that title.
A couple of points/observations/thoughts:
------------------------------
What seems to be the most compelling story for XMLBeans is not just that
it is a binding technology (which has been most emphasized in the past)
but that it is both a binding and store technology. By xmlbeans having
great xml schema support (at or nearly at 100% xml schema feature
support) and great xml infoset support (again, at or nearly at 100%
support) xmlbeans is an excellent candidate for making a standard in any
large enterprise.
I think it is likely that other binding only solutions will be faster in
the straight unmarshalling/marshalling to and from java objects since in
xmlbeans there is an xml store creation in the process (we don't know
the specific impact of this yet, Jamie Z is getting going on perf
testing and benchmarking so we can understand where we are). But can
these other specific binding solutions ever be your enterprise standard
for accessing/manipulating xml? This technology may work for your
*current* XML Schemas or your *current* documents but what about the
*next* schema that comes along that you did not anticipate, perhaps due
to a partner, industry, or just a data wonk in another department that
decides to use some of the fancier xml schema features. The same thing
for XML documents, what about if your app, or another app comes along
that needs to be see the entire xml infoset such as processing
instructions, order, mixed content models, etc.
It seems like other binding solutions, primarily by supporting only part
of xml schema (in particular type hierarchies) and dropping xml infoset
data that does not fit cleanly into java objects, must be "point"
solutions for particular applications that know they will not get xml
schemas or xml documents outside of certain parameters.
We tend to underplay the value of the store in the overall xmlbeans
value proposition. In v1 I think this is in large part due to the lack
of familiarity of using an xmlcursor model for access xml infoset. In
v2 xmlbeans supports both dom and xmlcursor natively for accessing the
store. In some ways it seems clearer to think about xmlbeans as a high
speed (right Eric?) xmlstore with dom/xmlcursor access with a powerful
java/xml binding model on top of it.
---------------------------------------
Using Xpath in conjunction with the XmlObject typed access is a great
way to reduce the amount of code needed to navigate a document. Using
selectPath on XmlObject returns typed objects from within the xml
document. Instead of doing 'gets' all the way to your specific item you
can do a single selectPath - *and* this will work for items with an
*any*.
---------------------------------------
Even though dom becomes a first class citizen in xmlbeans v2 I still
think xmlcursor is the fastest and best way to access low level store
data (which is why took this approach originally). Taking the time to
learn it will help you when you are wanting to write the highest speed
xml infoset access possible. We almost need a book on xmlcursor itself
to help people understand it better. One place to look for
documentation that you might not think of is the javadoc itself. There
is some really great javadoc including examples ... not enough overall
but something you might not have thought of.
------------------------------------------
The overwhelming feedback that I got at the end of the talk was that
xmlbeans needed better 'getting started' doc. We are going to work on
that.
-------------------------------------------
There were also a lot of questions about where the books are about
xmlbeans. I just finished and published my ws-security book so I am
ready to start an xmlbeans one right away. If you are interested in
writing an xmlbeans book I have been approached by several publishers
and might be able to help. The more xmlbeans books out there the better
....
----------------------------------------------------
The feeling that I got coming of EWorld was that people are really
resonating with what xmlbeans brings. Multiple people (high level
enterprise architects/devs) commented that they don't see any other
java/xml technologies that could be the "one" in-memory xml/java
technology that they could adopt for their shop. Also, individual
developers making the decision that xmlbeans was the place to invest
their valuable self education time and effort on xmlbeans for similar
reasons.
Just some thought,
rem
- ---------------------------------------------------------------------
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: EWorld ...
Posted by Steven Noels <st...@outerthought.org>.
On 28 May 2004, at 21:53, David Remy wrote:
> I spoke on Tues at EWorld about XMLBeans. I did a session called
> "Advanced XMLBeans" which was great because everyone that walked in
> sort
> of pre-qualified themselves just because they were willing to attend a
> talk with that title.
:-)
Thanks for a nice trip report!
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
- ---------------------------------------------------------------------
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: EWorld ...
Posted by Steven Noels <st...@outerthought.org>.
On 28 May 2004, at 21:53, David Remy wrote:
> I spoke on Tues at EWorld about XMLBeans. I did a session called
> "Advanced XMLBeans" which was great because everyone that walked in
> sort
> of pre-qualified themselves just because they were willing to attend a
> talk with that title.
:-)
Thanks for a nice trip report!
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source Java & XML An Orixo Member
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
- ---------------------------------------------------------------------
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: EWorld ...
Posted by Martin Wegner <ma...@yahoo.com>.
I have to second this. There is nothing out that we have found that comes
close to what XMLBeans can do, for both marshalling and unmarshalling.
In a closed world where you control both the schema and the
clients/servers you can probably get away with other options.
But if you are working with a broad range of schemas and new
clients/servers then XMLBeans appears to be the only game.
As you can tell we are very impressed with XMLBeans and are very glad it
is part of Jakarta.
--Marty
--- David Remy <dr...@bea.com> wrote:
> I spoke on Tues at EWorld about XMLBeans. I did a session called
> "Advanced XMLBeans" which was great because everyone that walked in sort
> of pre-qualified themselves just because they were willing to attend a
> talk with that title.
>
> A couple of points/observations/thoughts:
>
> ------------------------------
> What seems to be the most compelling story for XMLBeans is not just that
> it is a binding technology (which has been most emphasized in the past)
> but that it is both a binding and store technology. By xmlbeans having
> great xml schema support (at or nearly at 100% xml schema feature
> support) and great xml infoset support (again, at or nearly at 100%
> support) xmlbeans is an excellent candidate for making a standard in any
> large enterprise.
>
> I think it is likely that other binding only solutions will be faster in
> the straight unmarshalling/marshalling to and from java objects since in
> xmlbeans there is an xml store creation in the process (we don't know
> the specific impact of this yet, Jamie Z is getting going on perf
> testing and benchmarking so we can understand where we are). But can
> these other specific binding solutions ever be your enterprise standard
> for accessing/manipulating xml? This technology may work for your
> *current* XML Schemas or your *current* documents but what about the
> *next* schema that comes along that you did not anticipate, perhaps due
> to a partner, industry, or just a data wonk in another department that
> decides to use some of the fancier xml schema features. The same thing
> for XML documents, what about if your app, or another app comes along
> that needs to be see the entire xml infoset such as processing
> instructions, order, mixed content models, etc.
>
> It seems like other binding solutions, primarily by supporting only part
> of xml schema (in particular type hierarchies) and dropping xml infoset
> data that does not fit cleanly into java objects, must be "point"
> solutions for particular applications that know they will not get xml
> schemas or xml documents outside of certain parameters.
>
> We tend to underplay the value of the store in the overall xmlbeans
> value proposition. In v1 I think this is in large part due to the lack
> of familiarity of using an xmlcursor model for access xml infoset. In
> v2 xmlbeans supports both dom and xmlcursor natively for accessing the
> store. In some ways it seems clearer to think about xmlbeans as a high
> speed (right Eric?) xmlstore with dom/xmlcursor access with a powerful
> java/xml binding model on top of it.
>
> ---------------------------------------
>
> Using Xpath in conjunction with the XmlObject typed access is a great
> way to reduce the amount of code needed to navigate a document. Using
> selectPath on XmlObject returns typed objects from within the xml
> document. Instead of doing 'gets' all the way to your specific item you
> can do a single selectPath - *and* this will work for items with an
> *any*.
>
> ---------------------------------------
>
> Even though dom becomes a first class citizen in xmlbeans v2 I still
> think xmlcursor is the fastest and best way to access low level store
> data (which is why took this approach originally). Taking the time to
> learn it will help you when you are wanting to write the highest speed
> xml infoset access possible. We almost need a book on xmlcursor itself
> to help people understand it better. One place to look for
> documentation that you might not think of is the javadoc itself. There
> is some really great javadoc including examples ... not enough overall
> but something you might not have thought of.
>
> ------------------------------------------
>
> The overwhelming feedback that I got at the end of the talk was that
> xmlbeans needed better 'getting started' doc. We are going to work on
> that.
>
> -------------------------------------------
>
> There were also a lot of questions about where the books are about
> xmlbeans. I just finished and published my ws-security book so I am
> ready to start an xmlbeans one right away. If you are interested in
> writing an xmlbeans book I have been approached by several publishers
> and might be able to help. The more xmlbeans books out there the better
> ....
>
> ----------------------------------------------------
>
> The feeling that I got coming of EWorld was that people are really
> resonating with what xmlbeans brings. Multiple people (high level
> enterprise architects/devs) commented that they don't see any other
> java/xml technologies that could be the "one" in-memory xml/java
> technology that they could adopt for their shop. Also, individual
> developers making the decision that xmlbeans was the place to invest
> their valuable self education time and effort on xmlbeans for similar
> reasons.
>
> Just some thought,
> rem
>
>
> - ---------------------------------------------------------------------
> 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/
>
- ---------------------------------------------------------------------
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: EWorld ...
Posted by Martin Wegner <ma...@yahoo.com>.
I have to second this. There is nothing out that we have found that comes
close to what XMLBeans can do, for both marshalling and unmarshalling.
In a closed world where you control both the schema and the
clients/servers you can probably get away with other options.
But if you are working with a broad range of schemas and new
clients/servers then XMLBeans appears to be the only game.
As you can tell we are very impressed with XMLBeans and are very glad it
is part of Jakarta.
--Marty
--- David Remy <dr...@bea.com> wrote:
> I spoke on Tues at EWorld about XMLBeans. I did a session called
> "Advanced XMLBeans" which was great because everyone that walked in sort
> of pre-qualified themselves just because they were willing to attend a
> talk with that title.
>
> A couple of points/observations/thoughts:
>
> ------------------------------
> What seems to be the most compelling story for XMLBeans is not just that
> it is a binding technology (which has been most emphasized in the past)
> but that it is both a binding and store technology. By xmlbeans having
> great xml schema support (at or nearly at 100% xml schema feature
> support) and great xml infoset support (again, at or nearly at 100%
> support) xmlbeans is an excellent candidate for making a standard in any
> large enterprise.
>
> I think it is likely that other binding only solutions will be faster in
> the straight unmarshalling/marshalling to and from java objects since in
> xmlbeans there is an xml store creation in the process (we don't know
> the specific impact of this yet, Jamie Z is getting going on perf
> testing and benchmarking so we can understand where we are). But can
> these other specific binding solutions ever be your enterprise standard
> for accessing/manipulating xml? This technology may work for your
> *current* XML Schemas or your *current* documents but what about the
> *next* schema that comes along that you did not anticipate, perhaps due
> to a partner, industry, or just a data wonk in another department that
> decides to use some of the fancier xml schema features. The same thing
> for XML documents, what about if your app, or another app comes along
> that needs to be see the entire xml infoset such as processing
> instructions, order, mixed content models, etc.
>
> It seems like other binding solutions, primarily by supporting only part
> of xml schema (in particular type hierarchies) and dropping xml infoset
> data that does not fit cleanly into java objects, must be "point"
> solutions for particular applications that know they will not get xml
> schemas or xml documents outside of certain parameters.
>
> We tend to underplay the value of the store in the overall xmlbeans
> value proposition. In v1 I think this is in large part due to the lack
> of familiarity of using an xmlcursor model for access xml infoset. In
> v2 xmlbeans supports both dom and xmlcursor natively for accessing the
> store. In some ways it seems clearer to think about xmlbeans as a high
> speed (right Eric?) xmlstore with dom/xmlcursor access with a powerful
> java/xml binding model on top of it.
>
> ---------------------------------------
>
> Using Xpath in conjunction with the XmlObject typed access is a great
> way to reduce the amount of code needed to navigate a document. Using
> selectPath on XmlObject returns typed objects from within the xml
> document. Instead of doing 'gets' all the way to your specific item you
> can do a single selectPath - *and* this will work for items with an
> *any*.
>
> ---------------------------------------
>
> Even though dom becomes a first class citizen in xmlbeans v2 I still
> think xmlcursor is the fastest and best way to access low level store
> data (which is why took this approach originally). Taking the time to
> learn it will help you when you are wanting to write the highest speed
> xml infoset access possible. We almost need a book on xmlcursor itself
> to help people understand it better. One place to look for
> documentation that you might not think of is the javadoc itself. There
> is some really great javadoc including examples ... not enough overall
> but something you might not have thought of.
>
> ------------------------------------------
>
> The overwhelming feedback that I got at the end of the talk was that
> xmlbeans needed better 'getting started' doc. We are going to work on
> that.
>
> -------------------------------------------
>
> There were also a lot of questions about where the books are about
> xmlbeans. I just finished and published my ws-security book so I am
> ready to start an xmlbeans one right away. If you are interested in
> writing an xmlbeans book I have been approached by several publishers
> and might be able to help. The more xmlbeans books out there the better
> ....
>
> ----------------------------------------------------
>
> The feeling that I got coming of EWorld was that people are really
> resonating with what xmlbeans brings. Multiple people (high level
> enterprise architects/devs) commented that they don't see any other
> java/xml technologies that could be the "one" in-memory xml/java
> technology that they could adopt for their shop. Also, individual
> developers making the decision that xmlbeans was the place to invest
> their valuable self education time and effort on xmlbeans for similar
> reasons.
>
> Just some thought,
> rem
>
>
> - ---------------------------------------------------------------------
> 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/
>
- ---------------------------------------------------------------------
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/