RFC proposed change for data bindings alpha 5 dist

[Yuzo Kanomata <yuzok@ics.uci.edu>]

Hi All,

I've been thinking about the Enum val entity in the GXL dtd and I would 
like to propose a definition to add in the xsd.

First off, some background. In the gxl dtd Enum is defines as:

"<!-- enumeration value -->
<!ELEMENT enum    (#PCDATA) >

<!--
Values of an enumeration type
--> "

Okay, now to explain why PCDATA (which means parse-able CDATA, so 
essentially a string with possible control characters in it -- an old dtd 
catch-all def)is not enough for XML Schema(xsd) used for the data binding. 
First off, since no restriction is placed on what PCDATA is, essentially, 
all the stuff between <enum> tags would be be the enumeration value. This 
would mean that a client using such data would either have to know what the 
generator was thinking or do their best guess on the string.

In XML Schemas, base data types are defined to help users better define 
what was PCDATA is in a dtd. (see XML Schema data types: 
<http://www.w3.org/TR/xmlschema-2/>)

Looking the available types, 
<http://www.w3.org/TR/xmlschema-2/#built-in-datatypes>, NMTOKENS looks like 
a good candidate for me to declare enum to be.

To use this def, then the enums must be single space separated (with  no 
beginning white space or ending whitespace) seqences of NMTOKEN (String).

What that would look like in XML is:
<enum>alpha beta gamma delta</enum>

This makes it easy for the data binding generator to convert this to Java 
list with values "aplha" "beta" "gamma" "delta".

But there are consequences, e.g., if you decide that the XML should be like 
the following examples, then my def would not work:

Example 1)
<enum> a,b,c,d </enum>
Errors for my def: whitespace between > and a; white space at the end.
Note that this enum would not be: first=a, second=b, third=c, etc. but 
rather a single value string "a,b,c,d" because of no whitespace between the 
elements.

Example 2)
Similarly
<enum>a, b, c, d</enum>
would result in values: "a," "b," "c," "d" which would not be what the user 
expects, but what the binding would accept.

Example 3)

Note these two enums are not the same
<enum>a b c</enum>
<enum>a
b
c
</enum>
because you are putting in carriage return (and possibly line feed) between 
each element.

Considering these, I wanted to solicit feedback to see what enums are being 
used by the tools. Does anyone see a problem with my declaration of enums 
as NMTOKENS?

Yuzo