Arthur,
I understand your suggestion for the extension attributes defined in the
WSDL 2.0 spec, but for user-defined extension attributes there seem to be
two choices:
1) extension attributes should always have their own interface and
implementation class (like whttp:authenticationType does with
HTTPAuthenticationScheme and HTTPAuthenticationSchemeImpl), or
2) generic XMLAttr subtypes may suffice when the only constraints on the
extension attribute are those of its XML data type, but extension-specific
XMLAttr subtypes should be created when additional constraints exist.
#1 means more work for an extension developer, in that they need to define
an interface as well as an implementation for every attribute. In this
case, the XMLAttr approach is redundant, as this was intended as a generic
type-based mechanism that extension developers could reuse, so we should
remove the org.apache.woden.xml package and its generic XMLAttr subtypes
and put all extension-specific attribute types in the relevant extension
packages instead. We would need to add some common super type for ext
attributes in org.apache.woden.extensions and the
ExtensionRegistry.createExtAttribute method would then return this instead
of XMLAttr.
#2 is a better approach I think. If an extension developer just needs to
parse a simple attribute like a QName or Token without any additional
constraints they may choose to use a generic XMLAttr subtype like QNameAttr
or TokenAttr, but if they have additional constraints or they want their
extension's API to be more specific they can create their own XMLAttr
subtype to handle these.
However, the org.apache.woden.xml package should contain only generic types
and any extension-specific types like HTTPxxxx or SOAPxxxx should exist in
the relevant extension packages. So HTTPAuthenticationScheme would move to
...extensions.http and ArgumentArrayAttr would move to ...extensions.rpc.
And XMLAttr subtypes would be created in ...extensions.soap that mirror the
SOAP extensions in the WSDL 2.0 spec. The API package org.apache.woden.xml
should contain the classes for the generic types, rather than just the
interfaces, so that extension developers don't refer to Woden internal
classes when registering their ext attributes.
Any thoughts on #1 vs #2?
John Kaputin
Arthur Ryman
<[EMAIL PROTECTED]
> To
[email protected]
02/06/2006 16:16 cc
[email protected]
Subject
Please respond to Re: HTTPAuthenticationSchemeAttr
[EMAIL PROTECTED] versus TokenAttr
he.org
John,
I think the Woden API should mirror the WSDL 2.0 spec, which includes the
XSD. The XSD is normative. The spec says the authentication is an xs:token
but is restricted to "basis" and "digest". The textual spec doesn't provide
XSD types to enforce this but hte XSD document does.
I had a look at the XSD for HTTP and found 3 types:
<xs:attribute name='authenticationType'>
<xs:simpleType>
<xs:restriction base="xs:token">
<xs:enumeration value="basic"/>
<xs:enumeration value="digest"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:simpleType name="versionType">
<xs:restriction base="xs:string">
<xs:pattern value="[0-9]+\.[0-9]+"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="httpTokenType">
<xs:restriction base="xs:string">
<xs:pattern value="[!#-'*+\-.0-9A-Z^-z|~]+"/>
</xs:restriction>
</xs:simpleType>
I think we should define an interface and impl for each of these. So for
completeness, we should add the other two types, i.e. not just treat them
as th built-in simple types.
Arthur Ryman,
IBM Software Group, Rational Division
blog: http://ryman.eclipsedevelopersjournal.com/
phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: [EMAIL PROTECTED]
John Kaputin
<[EMAIL PROTECTED]>
To
[email protected]
06/02/2006 09:51 AM cc
Subject
Please respond to HTTPAuthenticationSchemeAttr
[email protected] versus TokenAttr
Arthur,
thanks for doing the HTTPEndpointExtension yesterday - I forgot this when
committing code on Wednesday.
There is something I'd like to change. You have created an implementation
of XMLAttr called HTTPAuthenticationSchemaAttrImpl and used this to
register the whttp:authenticationType extension attribute in
PopulatedExtensionRegistry. Previously I had this attribute registered with
the type TokenAttrImpl.
My API design goal for the XMLAttr subtypes in org.apache.woden.xml was to
represent XML data types with interfaces that could be reused by extension
attributes based on those data types. For example, any extension attribute
of type "xs:token" is represented by TokenAttr and in the absence of any
additional constraints on this attribute, it gets registered with the Java
type TokenAttrImpl, which contains deserialization and validation logic
common to all xs:token attributes. Likewise, QNameAttr for "xs:qname",
QNameListAttr for "list of xs:qname" and so on.
Your HTTPAuthenticationSchemaAttrImpl class caters for the fact that the
xs:token value in whttp:authenticationType must be "basic" or "digest".
This is OK. I do something similar with QNameOrTokenAnyImpl which caters
for the type "xs:qname or xs:token" where xs:token can only have the value
#any. However, that implementation class still implements the QNameOrToken
interface - there is no QNameOrTokenAny interface. The only additional
requirement here is in the validation logic provided by the implementation,
not in the methods required to access a QName or Token, so QNameOrToken is
a suitable interface for QNameOrTokenAnyImpl.
In this way the API interfaces in org.apache.woden.xml remain
representative of the underlying XML attribute data types and it's only in
org.apache.woden.internal.xml that we find implementation classes that add
validation constraints specific to particular attributes or categories of
attributes.
For consistency in the current API, I propose that we remove
HTTPAuthenticationSchemaAttr from org.apache.woden.xml and modify
HTTPAuthenticationSchemaAttrImpl so that it implements TokenAttr.
HTTPAuthenticationSchemaAttrImpl will still do the "basic" or "digest"
validation on the xs:token, but the HTTPEndpointExtensions.
getHttpAuthenicationScheme()method will return a TokenAttr rather than a
HTTPAuthenticationSchemaAttr and that method's javadoc can make an
appropriate statement about the permitted Token values.
I'm open to a more fundamental discussion about whether this approach is
good or not and in fact, I've posted separately about the XMLAttr approach
this morning in response to a suggestion from Jeremy. However, I'd prefer
any change resulting from such a discussion to be applied consistently
across the API, perhaps after the Interop event so that we can focus on
remaining function before then.
Do you agree with this change?
regards,
John Kaputin
Web Services Development, Hursley Laboratory
IBM United Kingdom Ltd
Hursley Park MP211, 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
