Brett Zamir wrote:
> However, I would still like to know why xs:Name is the type of choice
> here... For what good reason do these attribute values need to be
> xs:Name? I could understand if they should be NMTOKENS (plural) since
> that can allow multiple values and is looser than xs:Names (plural)
> (I've suggested this in a previous email but haven't gotten any
> responses on that one), but the only reason I can think of that a type
> should be constrained to xs:Name is if that attribute value might itself
> be converted into an XML element. Is that a common need?
Apologies for having overlooked your earlier question. The rationale
such as it is is as follows:
-- things identified as data.enumerated map to xs:Name because they are
typically coded values
-- if they are coded values they will usually be decoded by reference to
a <valItem> which has an @ident bearing the value concerned. That
attribute is defined as data.name
- if there is the possibility that multiple values may be needed as the
value for an attribute of type data.enumerated, this is indicated by the
@maxOccurs attribute of its <datatype> element.
If there are cases where you think the default value for this attribute
(1) is wrong, please shout now!
The argument was made, quite forcibly I think, that we should avoid the
inherent ambiguity in allowing spaces within attribute values. We want
to know that "foo bar" is actually ((foo)(bar)) and not (foo bar)!