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]
