On 7/6/06, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
Hello Jeremy and other woden devs,
and thanks for being so concerned about my problem ! I think that Woden is
already very useful and well tough despite the XMLSchema issue.
IMHO it's worst to rely on a specific XML Schema technology than on a
particular XML representation/parsing system (DOM, SAX,...). Because as soon as
a generic-xml parsing technology has been defined you can always provide
access-points in the API for people to plug their own domain-specific parsers
(like JaxMeXS for XML-Schemas for example). And this way you will automatically
be able to handle non-XML extension type systems.
At least DOM, SAX, StAX have standards-based APIs. Schema doesn't!
XML Schema seems like a good API to me, but it's clearly limited and I didn't
see any recent activity on the project page... But I also tend to think that a
lot of people are currently using the extensibility capabilities of XML Schema
(which the ws-commons xmlschema API fails to handle) and will use the
extensibility elements of WSDL 2.0 (already handled by Woden)... I need to use
both :-)
If you are able to give me access to a getSchemaElement() method, I'll have
first to check if it's possible to inject the DOM element object into an other
XML-Schema parser (like JaxMeXS).
The trouble is import (and include/redefine). When you inject the
schema Element object into another xml-schema parser it will likely
want to read the imported documents. These have already been read and
are in the XmlSchema model, but of course the secondary schema parser
isn't going to look for them there so it'll re-read them. Ideally
there would be a java standard for XML schema can both read and write
schema. AFAIK there isn't one. o.a.xerces.xs is one, but I think
doesn't do writes.
If you choose to fix XmlSchema, it would be a great idea to temporarily add the
getSchemaElement() method until XmlSchema is fixed :-) I'm sure I will be able
to retrieve the needed information from within the DOM Element on way or
another. It will always be better than the current situation where I have no
way whatsoever to access this information.
Either we add this method ... or create an 'SchemaSource' to wrapper
the DOM/SAX/StAX element like we did for WSDLSource. Then the user of
SchemaSource calls getSource() and casts to DOM/SAX/StAX or whatever.
That way we don't pollute the Woden API with DOM/SAX/StAX for the sake
of some type safety.
Perhaps we could then handle schema API pluggability in a similar way,
removing dependence on XmlSchema in the API.
Thoughts?
Jeremy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
