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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
