Lists Home |
Date Index |
- From: james anderson <firstname.lastname@example.org>
- To: "email@example.com" <firstname.lastname@example.org>
- Date: Fri, 26 Dec 1997 19:29:40 +0100
why are the elements of an enumarated attribute type specified to be
name tokens rather than attribute values? to wit:
 AttlistDecl ::= '<!ATTLIST' S Name AttDef* S? '>'
 AttDef := S Name S AttType S Default
 AttType ::= StringType | TokenizedType | EnumeratedType
 EnumeratedType ::= NotationType | Enumeration
 NotationType ::= 'NOTATION' S '(' S? Name (S? '|' Name)* S? ')'
 Enumeration ::= '(' S? Nmtoken (S? '|' S? Nmtoken)* S? ')'
 Default ::= '#REQUIRED' | '#IMPLIED' | (('#FIXED' S)? AttValue)
? isn't their domain actually attribute values, as in the example:
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.
type ("bullets"|"ordered"|"glossary") "ordered">
be both clearer and easier to implement ?
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)