John, The "correct" solution is to make MessageLabel an NCName, not a String.
-- Arthur On 11/29/05, John Kaputin <[EMAIL PROTECTED]> wrote: > Arthur, > I'll have a think about making MessageLabel extensible this week, while > working on MEPs and binding extensibility. If it isn't doable or if it > becomes too cumbersome in the framework (i.e. pgm model or configuration) > then we can revert to Strings. > > thanks, > John Kaputin > > > > > Arthur Ryman > <[EMAIL PROTECTED] > il.com> To > [email protected] > 28/11/2005 20:14 cc > > Subject > Please respond to Re: Using typesafe enums instead of > woden-dev Strings > > > > > > > > > > > John, > > That makes sense for Direction, but not {message label} since the > allowed values are an open set. Each MEP defines a set of message > labels, but anyone can define a new MEP that has new message labels. > > On 11/25/05, Jeremy Hughes <[EMAIL PROTECTED]> wrote: > > Trouble is enum is a reserved work in Java 5. Howabout using > > enumeration instead? > > > > Jeremy > > > > On 11/25/05, John Kaputin <[EMAIL PROTECTED]> wrote: > > > I have changed the representation of the {message label} property and > the > > > {direction} property from Strings to typesafe enumeration classes - > > > MessageLabel and Direction in a new package > org.apache.woden.wsdl20.enum. > > > The attached zip file contains the javadoc for these two > > > classes, containing a description and examples. > > > > > > (See attached file: TypesafeEnumJavadoc.zip) > > > > > > There are some other WSDL properties that could be represented this way > too > > > (e.g. NMTokens #element, #value, #none, etc). > > > > > > There are some Woden configuration constants currently represented as > > > strings and captured in the Constants file or in API interfaces which > could > > > perhaps be better represented as typesafe enums, but these should > probably > > > go in a new package org.apach.woden.enum. For example, a Feature enum > for > > > validation, tracing, etc and a Property enum for the type system, > parser > > > api, etc. > > > > > > These enums can be implemented as fixed or extensible, as needed. > > > > > > John Kaputin > > > > > > --------------------------------------------------------------------- > > > 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] > > > > > > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
