W3C home > Mailing lists > Public > xml-dist-app@w3.org > July 2002

Re: fault/detail

From: Martin Gudgin <martin.gudgin@btconnect.com>
Date: Tue, 23 Jul 2002 11:41:58 +0100
Message-ID: <001a01c23235$93006f90$b47ba8c0@zerogravitas>
To: <noah_mendelsohn@us.ibm.com>
Cc: "Jacek Kopecky" <jacek@systinet.com>, "Pete Hendry" <peter.hendry@capeclear.com>, <xml-dist-app@w3.org>


I would agree this issue is only worth fixing if we are delayed for other

I would note however that I would vote for making children of Detail
qualified rather than allowing children of Header and Body to be


----- Original Message -----
From: <noah_mendelsohn@us.ibm.com>
To: "Martin Gudgin" <martin.gudgin@btconnect.com>
Cc: "Jacek Kopecky" <jacek@systinet.com>; "Pete Hendry"
<peter.hendry@capeclear.com>; <xml-dist-app@w3.org>
Sent: Tuesday, July 23, 2002 1:59 AM
Subject: 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 Tuesday, 23 July 2002 06:41:52 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:01:20 UTC