- 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