ws-woden-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lawrence Mandel <lman...@ca.ibm.com>
Subject Re: Defining constants on the API vs. feature/property-specific methods
Date Wed, 19 Oct 2005 23:59:21 GMT
John,

Can you describe how the following features will be used?

verbose tracing
continue-parsing-on-error

Unless we have a use case for continue-on-fatal-error I'd like to suggest 
we do not include this in the Woden parser. The lack of understanding of 
the ramifications of using this feature in Xerces has caused confusion in 
Eclipse land.

Lawrence Mandel

As per the recent discussion thread, I have added some constants to the
WSDLReader interface representing identifiers for reader configuration
features (verbose tracing, validation, continue-parsing-on-error) and
properties (xml parser api, type system api).  Generic set/getFeature and
set/getProperty methods exist on WSDLReader for making use of these.

Another approach to consider is having feature or property-specific 
methods
for the small set of Woden-defined features and properties and of course,
keeping the generic methods for user-defined features and properties.

So on WSDLReader we'd create methods something like:

boolean isVerboseFeatureOn()
and
setVerboseFeatureOn() & setVerboseFeatureOff()
or just
setVerboseFeature(boolean)

We do this already for some potential config properties with
set/getErrorHandler(), set/getLocale() and set/getFactoryImplName() 
defined
on the WSDLReader interface. Again, whichever approach we take, we should
be consistent. Just a thought for now - can decide later, when we have a
better idea exactly what the Woden-defined features and properties will 
be.

regards,
John Kaputin


---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org



Mime
View raw message