You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commons-dev@ws.apache.org by Eran Chinthaka <ch...@opensource.lk> on 2006/07/17 13:05:17 UTC
[XmlSchema] StAX Integration
Hi all,
I would like to implement StAX support on top of XML schema so that one
can create an XML schema model from a StAX source. This will be helpful
especially in our efforts in integrating StAX in to Woden.
But the catch is if we write another SchemaBuilder for this purpose,
then there will be a StAX dependency on XmlSchema.
I would like to see a model where XML schema doesn't depend on any of
the underlying parsers, even on DOM.
Any idea on this will be highly appreciated.
Thanks,
Chinthaka
Re: [XmlSchema] StAX Integration
Posted by Ruchith Fernando <ru...@gmail.com>.
On 7/23/06, Ajith Ranabahu <aj...@gmail.com> wrote:
> Hi,
> Elegance apart - how often is the OM representation of a schema needs
> to become a XML schema representation ? Is this a woden scenario ?
>
> BTW after numerous encounters I also tend to think that DOM is quite
> convenient too (not to offend OM by any means. OM was designed with
> perf in mind and DOM was with accuracy in mind). It is 'accurate' and
> after a text to DOM conversion you have access to every information
> item that was there in text format so atleast that is 'pretty
> convenient' for me.
I agree with Ajith on this point.
and +1 for doing this with DOOM
Just my 0.02/= :-)
Thanks,
Ruchith
--
www.ruchith.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] StAX Integration
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi,
As I said even before there is no offence intended towards OM and I
also played a part in making it. Any blame on OM falls on me too.
> Seems this is becoming to an un-necessary argument, even after the
> solution being agreed.
>
Well it is not. An agreement is not implicit and I do not see an
explicit agreement in this thread at all. If this is a reference to
using DOOM then DOOM has a perfectly fine DOM API and the matter
becomes a configuration issue.
> Yes, it is. Wasn't it obvious from the first email itself? OM being an
> fully XML infoset compliant XML object model, don't you expect some one
> to have schema as an OMElement?
Of course I do expect that to happen . I want to figure out how often
that happens and how deep that integration should go. I'll be
outlining a possible solution for such cases (Glen would not be very
happy with it though)
>
> Anyway, I'd like to conclude this argument as we have a solution with DOOM.
What is the solution in exact terms ? As I said before using DOOM
becomes only a configuration issue (change the factory and that should
be it ). is that the solution we are talking about ?
>
> >
> > BTW after numerous encounters I also tend to think that DOM is quite
> > convenient too (not to offend OM by any means. OM was designed with
> > perf in mind and DOM was with accuracy in mind). It is 'accurate' and
> > after a text to DOM conversion you have access to every information
> > item that was there in text format so atleast that is 'pretty
> > convenient' for me.
>
> Are you saying OM is not giving access to *every* information item as in
> DOM? And OM is not accurate? If yes, since you are also an OM expert
> please fix it :).
Ok - I'm getting into a muddy area now. if you compare OM and DOM, DOM
has been around much longer and has been hammered on pretty much. This
means that it is now failry stable and complete as a piece of
software. Unfortunately OM did not get that sort of hammering at all
and every now and then you find subtle issues. I do fix bugs as and
when I find them but my point is as an API (and an implementation),
DOM has proved itself.
> OM, from the first day, designed to be convenient for the developer or
> the user. If there are inconveniences in OM, please bring them up. OM
> was there for more than 2 years. Why are these "blames" all of a sudden?
> For me, OM api is far more convenient than the cumbersome DOM api.
>
Its not a 'blame' and you should not get it personally either :) OM is
fine and convenient but if you remember the initial objective of OM
was performance. The full infoset support got into the picture later.
> > AFAIK XMLSchema strictly depends on the DOM api
>
> What is the base to this argument? Do you wanna create another
> xml-security model which is very in-flexible because its highly
> dependent on DOM apis.
Ok here is some food for thought. if you are designing an API that
needs to be pretty much extensible and it is going to be around for a
while AND it is going to have a certain XML API exposed, what is going
to be your choice? There are numerous XML object models out there
(and OM being one of them) so what would be your pick ? I'm pretty
sure that if you pick something other than DOM (the standard) there
will be quite a bit of critics on that. IMHO in a third party library
standpoint the best choice is DOM and xml-sec people did nothing wrong
in making the stuff on DOM.
I would say at this point that If I am to do something like the
xml-sec thing today, I would not expose the XMLish nature of it. Going
with that theory here's the best thing to do with XMLSchema in an
extensibility standpoint
1. Define a DOM free interface for the schema builder
2. DOM based schema builder becomes an implementation of that inteface
3. There is a SchemaBuilderFactory that provides builders to the
schemaCollection (oops - sorry Glen)
4. Stax based builder can be registered with the factory so that the
schema collection picks up that builder.
in essence the Stax based builder or the OM based builder lives inside
woden (or any other interesting project).
>
> IIUC, Xmlschema depends on DOM when it tries to build the schema model
> using the SchemaBuilder. This builder builds the schema model, looking
> at the DOM model. But if there is any attempt to make XmlSchema
> dependent on DOM, inside its model, other than in the above scenario,
> expect a -1 from me :).
Well you could put that -1 now if you want to. XML schema
serialization completely runs on the DOM API :)
>
> -- Chinthaka
>
>
>
>
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] StAX Integration
Posted by Eran Chinthaka <ch...@opensource.lk>.
Seems this is becoming to an un-necessary argument, even after the
solution being agreed.
Ajith Ranabahu wrote:
> Hi,
> Elegance apart - how often is the OM representation of a schema needs
> to become a XML schema representation ? Is this a woden scenario ?
Yes, it is. Wasn't it obvious from the first email itself? OM being an
fully XML infoset compliant XML object model, don't you expect some one
to have schema as an OMElement?
Anyway, I'd like to conclude this argument as we have a solution with DOOM.
>
> BTW after numerous encounters I also tend to think that DOM is quite
> convenient too (not to offend OM by any means. OM was designed with
> perf in mind and DOM was with accuracy in mind). It is 'accurate' and
> after a text to DOM conversion you have access to every information
> item that was there in text format so atleast that is 'pretty
> convenient' for me.
Are you saying OM is not giving access to *every* information item as in
DOM? And OM is not accurate? If yes, since you are also an OM expert
please fix it :).
OM, from the first day, designed to be convenient for the developer or
the user. If there are inconveniences in OM, please bring them up. OM
was there for more than 2 years. Why are these "blames" all of a sudden?
For me, OM api is far more convenient than the cumbersome DOM api.
>
> AFAIK XMLSchema strictly depends on the DOM api
What is the base to this argument? Do you wanna create another
xml-security model which is very in-flexible because its highly
dependent on DOM apis.
IIUC, Xmlschema depends on DOM when it tries to build the schema model
using the SchemaBuilder. This builder builds the schema model, looking
at the DOM model. But if there is any attempt to make XmlSchema
dependent on DOM, inside its model, other than in the above scenario,
expect a -1 from me :).
-- Chinthaka
Re: [XmlSchema] StAX Integration
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi,
Elegance apart - how often is the OM representation of a schema needs
to become a XML schema representation ? Is this a woden scenario ?
BTW after numerous encounters I also tend to think that DOM is quite
convenient too (not to offend OM by any means. OM was designed with
perf in mind and DOM was with accuracy in mind). It is 'accurate' and
after a text to DOM conversion you have access to every information
item that was there in text format so atleast that is 'pretty
convenient' for me.
AFAIK XMLSchema strictly depends on the DOM api and swithcing the
implementation is trivial :)
Ajith
On 7/23/06, Eran Chinthaka <ch...@opensource.lk> wrote:
> Hi,
>
> Glen Daniels wrote:
> > I'm not worried about the DOM dependency either. Schema processing is
> > typically (not always, but usually) going to be a design time thing
> > where squeaking every bit of performance out isn't as important.
>
> Its not about performance I'm talking here. Think of a situation where
> you have the whole WSDL in an OM tree. Do you want to get the schema
> element from it, build DOM and pump it to XmlSchema. I hope you won't
> say yes, if you care at least a lil bit about elegance.
>
> This is the exact thing Oshani is doing in her effort in integrating
> StAX support for Woden.
>
> > I *really* don't want to get into another whole "Yet Another XML Factory
> > Abstraction" thing unless we truly need it. And DOM is a pretty
> > convenient
>
> Since when you started to say DOM has a convenient API? I for one hates it.
> I can remember you were hating DOM apis a lot, during the first Axis2
> f2f and was very much impressed with JDom API.
>
> > (and standard, as Ajith points out) API for walking around an
> > XML tree with lots of cross-references.
>
> Anyway, I'm ok to go ahead with DOOM as Sanjiva suggested.
>
> -- Chinthaka
>
>
>
>
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] StAX Integration
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Eran:
Just a few clarifications...
Eran Chinthaka wrote:
> Glen Daniels wrote:
>> I'm not worried about the DOM dependency either. Schema processing is
>> typically (not always, but usually) going to be a design time thing
>> where squeaking every bit of performance out isn't as important.
>
> Its not about performance I'm talking here. Think of a situation where
> you have the whole WSDL in an OM tree. Do you want to get the schema
> element from it, build DOM and pump it to XmlSchema. I hope you won't
> say yes, if you care at least a lil bit about elegance.
Of course ideally not, but see the other thread (DOM and OM) also -
don't we have to pump a LLOM through a LLOM->DOM converter if we want to
use DOOM?
>> I *really* don't want to get into another whole "Yet Another XML Factory
>> Abstraction" thing unless we truly need it. And DOM is a pretty
>> convenient
>
> Since when you started to say DOM has a convenient API? I for one hates it.
> I can remember you were hating DOM apis a lot, during the first Axis2
> f2f and was very much impressed with JDom API.
To be clear, I didn't mean to say DOM is a *good* API. :) What I meant
by "convenient" is that it's standard and it's available everywhere.
XmlSchema seems like a library with a lot of potential usage both inside
and outside Apache - and since it doesn't have the huge need for
performance and integration with Axis that our WS-* extensions do, I
think it's actually probably a good thing that it doesn't depend on OM.
That doesn't mean I don't want it to work well with OM, just that I'm
wary about a dependency.
>> (and standard, as Ajith points out) API for walking around an
>> XML tree with lots of cross-references.
>
> Anyway, I'm ok to go ahead with DOOM as Sanjiva suggested.
+1, but see other thread for question about LLOM -> DOM performance.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] StAX Integration
Posted by Eran Chinthaka <ch...@opensource.lk>.
Hi,
Glen Daniels wrote:
> I'm not worried about the DOM dependency either. Schema processing is
> typically (not always, but usually) going to be a design time thing
> where squeaking every bit of performance out isn't as important.
Its not about performance I'm talking here. Think of a situation where
you have the whole WSDL in an OM tree. Do you want to get the schema
element from it, build DOM and pump it to XmlSchema. I hope you won't
say yes, if you care at least a lil bit about elegance.
This is the exact thing Oshani is doing in her effort in integrating
StAX support for Woden.
> I *really* don't want to get into another whole "Yet Another XML Factory
> Abstraction" thing unless we truly need it. And DOM is a pretty
> convenient
Since when you started to say DOM has a convenient API? I for one hates it.
I can remember you were hating DOM apis a lot, during the first Axis2
f2f and was very much impressed with JDom API.
> (and standard, as Ajith points out) API for walking around an
> XML tree with lots of cross-references.
Anyway, I'm ok to go ahead with DOOM as Sanjiva suggested.
-- Chinthaka
Re: [XmlSchema] StAX Integration
Posted by Glen Daniels <gl...@thoughtcraft.com>.
I'm not worried about the DOM dependency either. Schema processing is
typically (not always, but usually) going to be a design time thing
where squeaking every bit of performance out isn't as important. I
*really* don't want to get into another whole "Yet Another XML Factory
Abstraction" thing unless we truly need it. And DOM is a pretty
convenient (and standard, as Ajith points out) API for walking around an
XML tree with lots of cross-references.
My vote is to leave it alone for now, and then if we have performance
issues later we can consider changing it.
--Glen
Ajith Ranabahu wrote:
> Hi,
> I'm not really worried about the DOM dependancy. DOM API's are part of
> the JDK and it's not going to be 'taken off' so I personally think a
> DOM dependancy is not going to be any harm. But the stax dependancy is
> external and it is going to show up as soon as you enter something
> related to stax into the SchemaCollection.
> To overcome this I think we'll either have to change the schema
> builder architecture completley (to something like the factory
> pattern) or just live with the dependancy :)
>
>
> Ajith
>
>
> On 7/17/06, Eran Chinthaka <ch...@opensource.lk> wrote:
>> Hi all,
>>
>> I would like to implement StAX support on top of XML schema so that one
>> can create an XML schema model from a StAX source. This will be helpful
>> especially in our efforts in integrating StAX in to Woden.
>>
>> But the catch is if we write another SchemaBuilder for this purpose,
>> then there will be a StAX dependency on XmlSchema.
>> I would like to see a model where XML schema doesn't depend on any of
>> the underlying parsers, even on DOM.
>>
>> Any idea on this will be highly appreciated.
>>
>> Thanks,
>> Chinthaka
>>
>>
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] StAX Integration
Posted by Ajith Ranabahu <aj...@gmail.com>.
Hi,
I'm not really worried about the DOM dependancy. DOM API's are part of
the JDK and it's not going to be 'taken off' so I personally think a
DOM dependancy is not going to be any harm. But the stax dependancy is
external and it is going to show up as soon as you enter something
related to stax into the SchemaCollection.
To overcome this I think we'll either have to change the schema
builder architecture completley (to something like the factory
pattern) or just live with the dependancy :)
Ajith
On 7/17/06, Eran Chinthaka <ch...@opensource.lk> wrote:
> Hi all,
>
> I would like to implement StAX support on top of XML schema so that one
> can create an XML schema model from a StAX source. This will be helpful
> especially in our efforts in integrating StAX in to Woden.
>
> But the catch is if we write another SchemaBuilder for this purpose,
> then there will be a StAX dependency on XmlSchema.
> I would like to see a model where XML schema doesn't depend on any of
> the underlying parsers, even on DOM.
>
> Any idea on this will be highly appreciated.
>
> Thanks,
> Chinthaka
>
>
>
>
--
Ajith Ranabahu
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: DOM and OM
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hi Ruchith:
> IIRC one of the reasons we didn't pick the delegation model was
> because it forces us to hold on to _two_ object structures at the same
> point which didn't sound that cool since we were anyway forced to
> build the complete envelop to pump into WSS4J.
Gotcha, that makes sense. I guess another approach would have been to
just implement DOM directly in the LLOM classes but then that would
always bring in the DOM API too.
> But with DOOM you still get the same features of the LLOM OM impl
> (deferred built ..etc.), a DOM interface with a single object
> structure in memory and we can conveniently move DOOM in axis2 with
> out much of a hit on performance.
Sure, except that it's hard to go back and forth between the two
implementations, because you need to do some kind of translation step.
It's all tradeoffs, I suppose, and there's no perfect solution for all
use cases.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: DOM and OM (was: [XmlSchema] StAX Integration)
Posted by Ruchith Fernando <ru...@gmail.com>.
Hi,
IIRC one of the reasons we didn't pick the delegation model was
because it forces us to hold on to _two_ object structures at the same
point which didn't sound that cool since we were anyway forced to
build the complete envelop to pump into WSS4J.
But with DOOM you still get the same features of the LLOM OM impl
(deferred built ..etc.), a DOM interface with a single object
structure in memory and we can conveniently move DOOM in axis2 with
out much of a hit on performance.
Thanks,
Ruchith
On 7/25/06, Sanjiva Weerawarana <sa...@opensource.lk> wrote:
> On Mon, 2006-07-24 at 13:36 -0400, Glen Daniels wrote:
> > Hey Sanjiva:
> >
> > > However, the DOOM approach has an advantage- you get a DOM tree for the
> > > DOM-coolaids and you get an AXIOM tree for the OM-coolaids. See, you can
> > > in fact satisfy them all ;-).
> >
> > Well, sort of. :) Isn't DOOM a totally separate OM implementation? So
> > we can't just stream in a "standard" OM from somewhere (as a part of
> > normal message processing, let's say) and then use DOOM without
> > converting, right? And if you need to convert you have a performance
> > problem.
> >
> > What might be nice is a DOM implementation that truly sits "on top" of
> > OM, so you could do:
> >
> > OMElement om;
> > ...
> > Element dom = DOMWrapper.getDOMElement(om);
>
> Its nearly the same thing .. you call the DOOM builder giving the pull
> parser from the OM. Just a slight diff in API; result is a DOM element
> (which happens to be an OMElement too but you may not care about that).
>
> > Where we'd then have a "wrapper" DOM Element which just delegated calls
> > to its underlying OM implementation...
> >
> > Isn't that what we originally talked about when designing OM?
>
> We had *lots* of discussion since then on ways of implementing DOOM. If
> you recall we had a proto that did the delegation but that wasn't
> without issues. The current DOOM impl was the final form that we settled
> on and it works very well.
>
> Sanjiva.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>
--
www.ruchith.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: DOM and OM
Posted by Glen Daniels <gl...@thoughtcraft.com>.
>> OMElement om;
>> ...
>> Element dom = DOMWrapper.getDOMElement(om);
>
> Its nearly the same thing .. you call the DOOM builder giving the pull
> parser from the OM. Just a slight diff in API; result is a DOM element
> (which happens to be an OMElement too but you may not care about that).
The problem is that if you've already built the OM, the pull parser is
essentially deconstructing the build objects into XMLStreamReader
events, which are then used to build (yet another) in-memory model.
Right? That seems a) slow, and b) expensive.
I'll go check the archives for some of that discussion - I'm curious as
to what the issues with just delegating were.
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: DOM and OM (was: [XmlSchema] StAX Integration)
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Mon, 2006-07-24 at 13:36 -0400, Glen Daniels wrote:
> Hey Sanjiva:
>
> > However, the DOOM approach has an advantage- you get a DOM tree for the
> > DOM-coolaids and you get an AXIOM tree for the OM-coolaids. See, you can
> > in fact satisfy them all ;-).
>
> Well, sort of. :) Isn't DOOM a totally separate OM implementation? So
> we can't just stream in a "standard" OM from somewhere (as a part of
> normal message processing, let's say) and then use DOOM without
> converting, right? And if you need to convert you have a performance
> problem.
>
> What might be nice is a DOM implementation that truly sits "on top" of
> OM, so you could do:
>
> OMElement om;
> ...
> Element dom = DOMWrapper.getDOMElement(om);
Its nearly the same thing .. you call the DOOM builder giving the pull
parser from the OM. Just a slight diff in API; result is a DOM element
(which happens to be an OMElement too but you may not care about that).
> Where we'd then have a "wrapper" DOM Element which just delegated calls
> to its underlying OM implementation...
>
> Isn't that what we originally talked about when designing OM?
We had *lots* of discussion since then on ways of implementing DOOM. If
you recall we had a proto that did the delegation but that wasn't
without issues. The current DOOM impl was the final form that we settled
on and it works very well.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: DOM and OM (was: [XmlSchema] StAX Integration)
Posted by Glen Daniels <gl...@thoughtcraft.com>.
Hey Sanjiva:
> However, the DOOM approach has an advantage- you get a DOM tree for the
> DOM-coolaids and you get an AXIOM tree for the OM-coolaids. See, you can
> in fact satisfy them all ;-).
Well, sort of. :) Isn't DOOM a totally separate OM implementation? So
we can't just stream in a "standard" OM from somewhere (as a part of
normal message processing, let's say) and then use DOOM without
converting, right? And if you need to convert you have a performance
problem.
What might be nice is a DOM implementation that truly sits "on top" of
OM, so you could do:
OMElement om;
...
Element dom = DOMWrapper.getDOMElement(om);
Where we'd then have a "wrapper" DOM Element which just delegated calls
to its underlying OM implementation...
Isn't that what we originally talked about when designing OM?
--Glen
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] StAX Integration
Posted by Dan Diephouse <da...@envoisolutions.com>.
Sanjiva Weerawarana wrote:
>On Wed, 2006-07-26 at 02:11 -0700, Dan Diephouse wrote:
>
>
>>I still don't understand what we're trying to do here. I understood that
>>they just wanted to create a xmlschema from a stax stream. If so, the
>>STAXUtils class does it in like a 100 lines of code with no added
>>dependencies. If we're trying to support OM, that is a completely
>>different story. Can someone clarify what concrete objectives we're
>>trying to achieve? Either way I'm completely -1 on a hard stax or axiom
>>dependency.
>>
>>
>
>If that was desired the right way to do it would to have different
>builders, one which builds from DOM and one which builds from
>StaX/AXIOM. The current builders would be the DOM based one of course.
>You can't possibly -1 providing that flexibility right Dan? No one is
>forcing you to use AXIOM and you can't force others to use DOM. Live and
>let live. ;-).
>
>
I'm not -1'ing that feature. I just don't want either stax or axiom to
be required to use xml schema.
>Using AXIOM gives a much faster underlying rep that DOM and, in this
>case, DOM is not required (unlike with the security stuff). So one could
>make a case for doing a StaX/AXIOM builder easily. And furthermore,
>because Axis2 and various other projects do use AXIOM its perfectly
>legitimate to have a StaX/AXIOM builder so that that world can live on
>comfortably in one single XML Infoset representation.
>
>
>
Yes, it is perferectly fine. I said "hard dependency", not soft dependency.
>Anyway, no one is proposing that yet AFAIK. Using DOOM seems to address
>the objectives right now (of not requiring anything except AXIOM) but I
>wanted to establish the principal above.
>
I'm totally ok with anyone doing stax, or axiom or DOOM or whatever as a
soft dependency. I was trying to understand the objectives. Performance?
Stax compatability? AXIOM integration? It doesn't really matter, I just
don't want a a hard dependency on anything.
- Dan
--
Dan Diephouse
(616) 971-2053
Envoi Solutions LLC
http://netzooid.com
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] StAX Integration
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Wed, 2006-07-26 at 02:11 -0700, Dan Diephouse wrote:
> I still don't understand what we're trying to do here. I understood that
> they just wanted to create a xmlschema from a stax stream. If so, the
> STAXUtils class does it in like a 100 lines of code with no added
> dependencies. If we're trying to support OM, that is a completely
> different story. Can someone clarify what concrete objectives we're
> trying to achieve? Either way I'm completely -1 on a hard stax or axiom
> dependency.
If that was desired the right way to do it would to have different
builders, one which builds from DOM and one which builds from
StaX/AXIOM. The current builders would be the DOM based one of course.
You can't possibly -1 providing that flexibility right Dan? No one is
forcing you to use AXIOM and you can't force others to use DOM. Live and
let live. ;-).
Using AXIOM gives a much faster underlying rep that DOM and, in this
case, DOM is not required (unlike with the security stuff). So one could
make a case for doing a StaX/AXIOM builder easily. And furthermore,
because Axis2 and various other projects do use AXIOM its perfectly
legitimate to have a StaX/AXIOM builder so that that world can live on
comfortably in one single XML Infoset representation.
Anyway, no one is proposing that yet AFAIK. Using DOOM seems to address
the objectives right now (of not requiring anything except AXIOM) but I
wanted to establish the principal above.
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] StAX Integration
Posted by Dan Diephouse <da...@envoisolutions.com>.
Sanjiva Weerawarana wrote:
>On Fri, 2006-07-21 at 20:29 -0400, Dan Diephouse wrote:
>
>
>>Or just steal the Document building code from here:
>>
>>http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-core/src/main/org/codehaus/xfire/util/STAXUtils.java?r=1775#l406
>>
>>
>
>Yeah been there done that a long time ago .. with XPP.
>
>However, the DOOM approach has an advantage- you get a DOM tree for the
>DOM-coolaids and you get an AXIOM tree for the OM-coolaids. See, you can
>in fact satisfy them all ;-).
>
>Sanjiva.
>
>
>
I still don't understand what we're trying to do here. I understood that
they just wanted to create a xmlschema from a stax stream. If so, the
STAXUtils class does it in like a 100 lines of code with no added
dependencies. If we're trying to support OM, that is a completely
different story. Can someone clarify what concrete objectives we're
trying to achieve? Either way I'm completely -1 on a hard stax or axiom
dependency.
- Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] StAX Integration
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
On Fri, 2006-07-21 at 20:29 -0400, Dan Diephouse wrote:
> Or just steal the Document building code from here:
>
> http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-core/src/main/org/codehaus/xfire/util/STAXUtils.java?r=1775#l406
Yeah been there done that a long time ago .. with XPP.
However, the DOOM approach has an advantage- you get a DOM tree for the
DOM-coolaids and you get an AXIOM tree for the OM-coolaids. See, you can
in fact satisfy them all ;-).
Sanjiva.
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] StAX Integration
Posted by Dan Diephouse <da...@envoisolutions.com>.
Or just steal the Document building code from here:
http://svn.xfire.codehaus.org/browse/xfire/trunk/xfire/xfire-core/src/main/org/codehaus/xfire/util/STAXUtils.java?r=1775#l406
- Dan
Sanjiva Weerawarana wrote:
> Can we use DOOM and get the best of both worlds?
>
> Sanjiva.
>
> On Mon, 2006-07-17 at 16:35 +0530, Eran Chinthaka wrote:
>
>> Hi all,
>>
>> I would like to implement StAX support on top of XML schema so that one
>> can create an XML schema model from a StAX source. This will be helpful
>> especially in our efforts in integrating StAX in to Woden.
>>
>> But the catch is if we write another SchemaBuilder for this purpose,
>> then there will be a StAX dependency on XmlSchema.
>> I would like to see a model where XML schema doesn't depend on any of
>> the underlying parsers, even on DOM.
>>
>> Any idea on this will be highly appreciated.
>>
>> Thanks,
>> Chinthaka
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: commons-dev-help@ws.apache.org
>
>
--
Dan Diephouse
Envoi Solutions
http://envoisolutions.com
http://netzooid.com/blog
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org
Re: [XmlSchema] StAX Integration
Posted by Sanjiva Weerawarana <sa...@opensource.lk>.
Can we use DOOM and get the best of both worlds?
Sanjiva.
On Mon, 2006-07-17 at 16:35 +0530, Eran Chinthaka wrote:
> Hi all,
>
> I would like to implement StAX support on top of XML schema so that one
> can create an XML schema model from a StAX source. This will be helpful
> especially in our efforts in integrating StAX in to Woden.
>
> But the catch is if we write another SchemaBuilder for this purpose,
> then there will be a StAX dependency on XmlSchema.
> I would like to see a model where XML schema doesn't depend on any of
> the underlying parsers, even on DOM.
>
> Any idea on this will be highly appreciated.
>
> Thanks,
> Chinthaka
>
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org