attlistdecl (nmtoken vs attvalue) in enumeration

james anderson mecom-gmbh at
Fri Dec 26 18:29:59 GMT 1997


why are the elements of an enumarated attribute type specified to be
name tokens rather than attribute values? to wit:
[52] AttlistDecl ::=  '<!ATTLIST' S Name AttDef* S? '>'
[53] AttDef := S Name S AttType S Default
[54] AttType ::= StringType | TokenizedType | EnumeratedType
[57] EnumeratedType ::= NotationType | Enumeration
[58] NotationType ::=  'NOTATION' S '(' S? Name (S? '|' Name)* S? ')'
[59] Enumeration ::=  '(' S? Nmtoken (S? '|' S? Nmtoken)* S? ')'
[60] Default ::= '#REQUIRED' | '#IMPLIED'  | (('#FIXED' S)? AttValue)

? isn't their domain actually attribute values, as in the example:
<!ATTLIST list
                    type    (bullets|ordered|glossary)  "ordered">

? since name characters constitute a smaller domain than attribute value
characters don't you end up with attribute values which can't be
included in the enumeration constraint?

? even without the distinction in character range, isn't this conflating
two domains - that of interned tokens and that of string values - which
are better of kept distinct. either the constraints look like tokens,
but must be parsed as if they were strings, or the constraint evaluation
must permit tokens to be compared to strings.

? wouldn't
<!ATTLIST list
                    type    ("bullets"|"ordered"|"glossary")  "ordered">

be both clearer and easier to implement ?

thanks, bye,

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at
Archived as:
To (un)subscribe, mailto:majordomo at the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at

More information about the Xml-dev mailing list