W3C home > Mailing lists > Public > xml-editor@w3.org > April to June 2001

Re: Section 3.3.x questions/comments

From: Richard Tobin <richard@cogsci.ed.ac.uk>
Date: Sat, 7 Apr 2001 21:17:47 +0100 (BST)
Message-Id: <200104072017.VAA13016@banks.cogsci.ed.ac.uk>
To: "Glenn Marcy" <gmarcy@us.ibm.com>, xml-editor@w3.org
Cc: Richard Tobin <richard@cogsci.ed.ac.uk>, "Arnaud Le Hors" <lehors@us.ibm.com>
> 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 


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.

 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.


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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:12:39 UTC