Extend enumeration types to allow values other than strings

[michaelhkay]

In reviewing and accepting the spec for enumeration types, it was suggested that it might be useful to allow values other than strings.

• There's a difficulty in that not all atomic values can be represented by literals. We have the same problem with function annotations; perhaps we need to bite the bullet and define some kind of "constant atomic expression" construct.
• Aside from that, there don't seem to be any major obstacles.

We change

An EnumerationType has a value space consisting of a set of xs:string values. When matching strings against an enumeration type, strings are always compared using the Unicode codepoint collation.

to

An EnumerationType has a value space consisting of a set of atomic values. When matching values against an enumeration type, values are always compared using the fn:atomic-compare() function (as used for comparing map keys).

The subtyping rules (newly defined in terms of unions of singleton enumeration sets) seem to work in their current form, without change. enum("red", "green") is still a subtype of xs:string, because all the enumerated values are instances of xs:string.

[michaelhkay]

Hmmm. If enumeration values are compared using fn:atomic-compare(), then 1.0e0 is an instance of enum(0, 1, 2), which means that enum(0, 1, 2) cannot be a subtype of xs:integer.

[ChristianGruen]

Related: #283

[michaelhkay]

I think the complications, especially those involving cross-type equality comparisons, mean that the costs of this feature don't justify the benefits, so I propose we close with no action.

[ndw]

The group agreed to close this issue without action at meeting 054