You are viewing a plain text version of this content. The canonical link for it is here.
Posted to woden-dev@ws.apache.org by John Kaputin <KA...@uk.ibm.com> on 2005/10/24 13:41:55 UTC
Re: Questions/concerns that came up while working on validation
1. ErrorReporter
--------------------
I based ErrorReporter on the Xerces approach, which only exposes the
ErrorHandler on the API. But as we would like Woden extensions to use a
common error reporting mechanism, we should make the ErrorReporter public
on the API (just its interface?). Currently its reportError method calls
MessageFormatter.formatMessage to convert the error id and the msg args
into a formatted message string using the Messages.props resource bundle. I
will assume MessageFormatter will remain internal (not on the API) and when
the Woden implementation reports an error it first calls the formatMessage
method to get the string to pass to reportError (and reportError signature
and implementation get changed to reflect this usage).
An alternative would be to overload the reportError method to support both
signatures (message args or formatted message). We would then need to
consider how extensions use the reportError signature that takes message
args:
a) Just raise an error if the error id arg is not recognized? This
effectively limits error ids to those in the Woden Messages.props bundle
(Woden config errors and W3C WSDL asserts).
b) Allow extensions to supply their own message resource bundles and change
Woden to search beyond its own Messages.props bundle?
2. reportError declares WSDLException
--------------------------------------------------
Our strategy is to terminate on a fatal parsing error and the WSDLException
thrown by reportError is currently the way we do this. On a fatal-error the
method either rethrows any existing WSDLException passed in as the
targetException arg on the reportError call or throws a new WSDLException,
wrapping any non-WSDL targetException passed in. The idea was that this
would bubble up to be exposed to the calling application, which means all
methods in the call path in Woden would need to declare the WSDLException.
This was a way of enforcing the terminate on fatal error strategy (i.e. do
it in the error handling mechanism). If we remove this use of WSDLException
in reportError, it's then up to the code that calls reportError to check if
the error reported is fatal and if so, terminate. To avoid inconsistencies
in applying the strategy, I could look into encapsulating the
terminate-or-not decision in some internal way that gets used following a
call to reportError from within the Woden code - i.e. so that it applies
only to the Woden implementation, not to any extensions that use
ErrorReporter.
Another approach would be to define in ErrorReporter a method for reporting
non-fatal errors (e.g. reportNonFatalError) and a reportFatalError method,
with only the latter declaring that it throws WSDLException. But that
sounds messy in the calling logic and it may not help with the extensions
issue.
Let's discuss this further, then re-post to the mailing list.
3. ws-commons XmlSchema
------------------------------------
We can move to XmlSchema any time, we just won't be able to pass some of
the W3C WSDL 2.0 test cases until the XmlSchema issues I reported earlier
are fixed. I won't have time to look at XmlSchema fixes immediately - maybe
later in November. But I can change Woden from W3C XMLSchema back to
ws-commons XmlSchema sooner if it helps your development and we can just
stick with schemas that work for now.
4. TypesElement.getTypeSystem()
------------------------------------------
I think I based the single type system per document idea on this statement,
which leaves the use of multiple type systems with a <types> element
undefined...
Part 2, Section 3.2 Using Other Schema Languages:
This specification does not define the behavior of a WSDL 2.0 document that
uses multiple schema languages for describing type system components
simultaneously.
I had this property on the Schema originally, but move it to TypesElement
in M1. It won't be too important until we look at type system extensions
for non-XML Schema type systems (M4/M5 timeframe?) so we could just remove
it for now.
regards,
John Kaputin
Web Services Development
Hursley Laboratory
IBM UK Ltd, MP211, Hursley Park, Winchester, SO21 2JN, UK.
email: kaputin@uk.ibm.com
Tel/Fax: +44 (0)1962 817363 (internal 7-247363)
Lawrence Mandel
<lmandel@ca.ibm.c
om> To
woden-dev@ws.apache.org
23/12/2005 22:02 cc
Subject
Please respond to Questions/concerns that came up
woden-dev while working on validation
While working on the validation logic for types I came across some areas in
Woden for which I have questions/concerns:
1. The current Woden error reporter takes a key and some arguments when
reporting an error. This method will not allow extension validator or
parser providers (those that will plug into Woden) to report errors other
than those included in Woden. I suggest we change this method to take an
error id, string, and location information and make the reporter publically
available. John, is there a problem with changing the error reporter?
2. The reportError method currently defines that it may throw an exception
when reporting an error. I don't think this is a good design decision as
error reporting will be used in many locations throughout Woden and its
extenders. Does this method need to throw an exception? I'd prefer to see
this type of error logged somewhere or reported as an internal error
without throwing an exception.
3. Woden currently relies on Xerces' XSModel API. We discussed moving to
the Schema model from WS commons. Can this change be contained in M2?
Validation of inline and imported schemas will depend to some extent on the
schema model in use. From my perspective, the sooner this is complete the
better. Also, the sooner we move to the WS commons Schema model the sooner
we can identify any problems with the model.
4. The TypesElement has a method getTypeSystem, the description of which
states that "Indicates the type system used within the <types>
element." I don't see anywhere in the WSDL 2.0 spec where a WSDL document
is limited to using only one types system in a WSDL document. For example,
I believe it is valid to reference a schema grammar and a Relax NG grammar
in the same WSDL document.
Thanks,
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
lmandel@ca.ibm.com
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org