This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
QT approved comment The Note at the end of section 2.6.1.3 seems both misplaced and irrelevant. The same applies to the similar notes in 2.6.2 and 2.6.4. The general effect of these notes is to make the reader ask "Why are they telling me not to worry about this? Is there something I've missed?".
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.
decided this date by wg to delete the notes as proposed in comment 1
The change outlined in comment #1 and approved in September 2007 was integrated into the status-quo document in October 2007. (That fact should have been noted here earlier, but there were distractions.) Michael, as the individual who entered the issue on behalf of QT, could you at some convenient point report the WG's disposition of the issue back to QT and let us know in the usual way whether QT is content with that disposition or not, by changing the status either to CLOSED or to REOPENED? Thank you.
Since the response addresses all the concerns expressed in the original comment, I feel able to close this. Thanks.