1) +1. I think I added the ReaderFeatures class to have one place to contain all the specified features. These can be specified on the reader (this may be simplest) or we can externalize the ReaderFeatures class. For the current docs I vote to go with WSDLReader.FEATURE_VALIDATION as you suggested.
2) -1. I don't think we should specify methods specifically for enabling every feature. Doing this will add noise to the API and is not scalable. (Every feature requires a new enablement method.) This also leads to two ways to specify features. I think we should learn from Xerces and use the feature framework we've got in place to specify all of our features.
Lawrence Mandel
Software Developer
IBM Rational Software
Phone: 905 - 413 - 3814 Fax: 905 - 413 - 4920
[EMAIL PROTECTED]
| John Kaputin <[EMAIL PROTECTED]>
01/27/2006 08:41 AM
|
|
I came across this issue while writing the user guide.
The validation feature identifier
"http://ws.apache.org/woden/features/validation" is currently defined as a
static final in 2 places:
WSDLReader.FEATURE_VALIDATION
ReaderFeatures.VALIDATION_FEATURE_ID
The M3 release notes describe enabling validation by setting
ReaderFeatures.VALIDATION_FEATURE_ID to true, but this is an internal
class. We can correct this easily in various ways:
1) by specifying WSDLReader.FEATURE_VALIDATION for the programming model
(i.e. rather than exposing an interface for ReaderFeatures on the API).
2) by removing the static finals for pre-defined features like validation
from the WSDLReader interface and adding specific methods for those
pre-defined features - for example, setValidation(boolean) and
isValidationEnabled(). Other pre-defined features are CONTINUE-ON-ERROR and
VERBOSE (i.e. trace).
Option 2) would require more methods on the API but it would remove the
need to explicitly define identifiers for these pre-defined features in the
API. Then only user-defined features would need to use the setFeature(..)
and getFeature() methods on WSDLReader. Ditto for properties.
For now, to complete the user guide I'll go with Option 1) because it will
work with the existing implementation.
It's really a style thing - both approaches work. I remember proposing
option 1) originally, but I now prefer option 2) because I think it makes
the reader API more obvious and it offers better encapsulation (i.e. no
identifiers are required externally for pre-defined features).
Please comment or vote if you have a preference.
John Kaputin
Web Services Development
Hursley Laboratory
IBM UK Ltd, MP211, Hursley Park, Winchester, SO21 2JN, UK.
email: [EMAIL PROTECTED]
Tel/Fax: +44 (0)1962 817363 (internal 7-247363)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
