Re: Section 3.3.x questions/comments

> Q1:
> 
> The following declaration seems a bit odd, but is it valid?
> 
>   <!ATTLIST root a NOTATION (a|a) "a">
> 
> The Section 3.3.1, the spec says:
> 
> "For interoperability, the same Nmtoken should not occur more than once in
> the enumerated
> attribute types of a single element type."
> 
> Is the same true for the Name choices in NOTATION attributes?  Does the
> spec say this?

There is an erratum to the second edition 

  http://www.w3.org/XML/xml-V10-2e-errata#E2

which says

 Add a validity constraint applying to productions [58] NotationType
 and [59] Enumeration as follows:

 Validity constraint: No duplicate tokens 
 The notation names in a single NotationType attribute declaration, as
 well as the NmTokens in a single Enumeration attribute declaration,
 must all be distinct.

 Rationale 
 Necessary to maintain compatibility with SGML. 

The interoperability constraint you quote is much more restrictive;
it relates to the fact that attribute names can be omitted in SGML,
so you can't even do

  <!ATTLIST root a (true|false)
                 b (true|false)>

because <a true> would be ambiguous.  Since it's just an
interoperability constraint, you can ignore it.


> Q2:
> 
> In Section 3.3.1, all of the VC's for TokenizedType attribute types use the
> phrase:
> 
>   Values of type X must match the Y production.
> 
> The VC's for EnumeratedType attribute types use phrase:
> 
>   Values of this type must match one of the <Y things> in the declaration.
> 
> The second case seems less precise.  In particular, if I had an attribute
> declared as:
> 
>   <!ATTLIST root a (A|B) " &#xd;A ">
> 
> While the normalized value of "#xD A" does not "match the Nmtoken
> production", I feel on less secure footing
> that is doesn't "match one of the Nmtoken tokens in the declaration", which
> might be attributed to implementation
> "laziness" and not to adherence to the specification.

I don't see this.  The normalized value definitely doesn't match A or
B (NB "match" is defined in the Terminology section).  Am I missing
your point here?

> Q3:
> 
> Once the issue of (E108 vs. E62) is resolved, Section 3.3.3 might want to
> say that if a character reference to a
> whitespace character other than #x20 appears directly in a non-CDATA
> attribute, the attribute will be well-formed,
> but invalid.  Direct wording would be stronger than attempting to glean
> this fact from the examples.

Noted.

-- Richard

Received on Saturday, 7 April 2001 16:19:42 UTC