- From: <bugzilla@wiggum.w3.org>
- Date: Fri, 21 Sep 2007 04:08:23 +0000
- To: www-xml-schema-comments@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=3237
cmsmcq@w3.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |needsPublication
------- Comment #1 from cmsmcq@w3.org 2007-09-21 04:08 -------
Proposal: delete the three notes in question. For the record, I mean:
1) the note at the end of 2.4.1.3 Union datatypes which reads
Note: A datatype which is ·atomic· in this specification need
not be an "atomic" datatype in any programming language used
to implement this specification. Likewise, a datatype which
is a ·list· in this specification need not be a "list"
datatype in any programming language used to implement
this specification. Furthermore, a datatype which is a
·union· in this specification need not be a "union" datatype
in any programming language used to implement this specification.
2) the note at the end of 2.4.2 Special vs. Primitive vs. Ordinary
Datatypes which reads:
Note: A datatype which is ·primitive· in this specification
need not be a "primitive" datatype in any programming
language used to implement this specification. Likewise,
a datatype which is ·constructed· in this specification
from some other datatype need not be a "derived" datatype
in any programming language used to implement this specification.
3) the note at the end of 2.4.4 Built-in vs. User-Defined Datatypes
which reads
Note: A datatype which is ·built-in· in this specification
need not be a built-in datatype in any programming language
used to implement this specification. Likewise, a datatype
which is ·user-defined· in this specification need not be
a user-defined datatype in any programming language used
to implement this specification.
The point these notes are trying to make is in fact a simple and obvious
one, although it is not hard to find, even among W3C working groups, smart
programmers who uncritically assume a particular mapping between the
formulations of a specification and the data structures or APIs the
programmers will use. (Arguments over whether to refer to
the in-scope namespaces or the namespace attributes property of the
infoset, for example, routinely make the kind of mistake warned against
by these notes. And the idea that an information set is either a kind
of data structure or a kind of API can be met with even today, among
Working Group members who really ought to know better.) But the notes
do not appear specially effective in encouraging the appropriate mental
hygiene. If they puzzle some readers in QT, then, let us excise them.
Received on Friday, 21 September 2007 04:08:28 UTC