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 2006/01/27 14:41:05 UTC
Exposing WSDLReader features on the API
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: kaputin@uk.ibm.com
Tel/Fax: +44 (0)1962 817363 (internal 7-247363)
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org
Re: Exposing WSDLReader features on the API
Posted by Lawrence Mandel <lm...@ca.ibm.com>.
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
lmandel@ca.ibm.com
John Kaputin <KA...@uk.ibm.com>
01/27/2006 08:41 AM
Please respond to
woden-dev
To
woden-dev@ws.apache.org
cc
Subject
Exposing WSDLReader features on the API
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: kaputin@uk.ibm.com
Tel/Fax: +44 (0)1962 817363 (internal 7-247363)
---------------------------------------------------------------------
To unsubscribe, e-mail: woden-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: woden-dev-help@ws.apache.org