Re: fault/detail

I think at this stage it's important to take account of the W3C process as 
well as the technical niceties.  After well over a year of discussion, the 
specification has gone to "last call".  For better or worse, even modest 
functional changes or additions (not deletions) are likely to introduce at 
least weeks and probably months of process overhead, because W3C rules say 
we'd go back to last call with the whole specification.  This is not the 
place to debate the merits of the W3C process.  It's got some good and 
some bad characteristics, but one of the things we must now do is to set 
the bar a bit higher on "nice-to-have" changes.  Anyone who ships 
commercial software recognizes this point in the product process, where 
stability of the spec becomes important along with its design 
characteristics. 

Therefore, I think we need to carefully sort proposed changes into at 
least three piles:

* Worth changing even if it delays the publication of the spec for, say, 
2+ months
* Worth changing only if the spec is delayed for other reasons.
* Wouldn't change it even if there were no delay

I think the proposal to change the qualification of detail rates no higher 
than the middle group, at best.   Getting rid of qualification on headers 
and bodies is a very bad idea, IMO, as it undercuts the whole "understand" 
mechanism.   We say that each header entry must have a QName that is 
described in some specification of which the receiving software is aware 
and with which it is conformant.  Making that statement about an 
unqualified name seems risky at best.  Thank you.

------------------------------------------------------------------
Noah Mendelsohn                              Voice: 1-617-693-4036
IBM Corporation                                Fax: 1-617-693-8676
One Rogers Street
Cambridge, MA 02142
------------------------------------------------------------------

Received on Monday, 22 July 2002 21:00:58 UTC