From owner-sc22wg5@open-std.org  Wed Mar 17 14:25:52 2010
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom8
Delivered-To: sc22wg5-dom8@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id 3BA1AC178DF; Wed, 17 Mar 2010 14:25:52 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from mk-filter-2-a-1.mail.uk.tiscali.com (mk-filter-2-a-1.mail.uk.tiscali.com [212.74.100.53])
	by www2.open-std.org (Postfix) with ESMTP id AC9D7C178D9
	for <sc22wg5@open-std.org>; Wed, 17 Mar 2010 14:25:50 +0100 (CET)
X-Trace: 365138729/mk-filter-2.mail.uk.tiscali.com/B2C/$b2c-THROTTLED-DYNAMIC/b2c-CUSTOMER-DYNAMIC-IP/88.106.91.254/None/d.muxworthy@bcs.org.uk
X-SBRS: None
X-RemoteIP: 88.106.91.254
X-IP-MAIL-FROM: d.muxworthy@bcs.org.uk
X-SMTP-AUTH: 
X-MUA: Apple Mail (2.753.1)
X-IP-BHB: Once
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ApEBAIN1oEtYalv+/2dsb2JhbAAH1gSEdgQ
X-IronPort-AV: E=Sophos;i="4.49,657,1262563200"; 
   d="scan'208";a="365138729"
Received: from 88-106-91-254.dynamic.dsl.as9105.com (HELO [192.168.1.2]) ([88.106.91.254])
  by smtp.tiscali.co.uk with ESMTP; 17 Mar 2010 13:25:47 +0000
In-Reply-To: <20100317081909.9DEC5C178D9@www2.open-std.org>
References: <20100317081909.9DEC5C178D9@www2.open-std.org>
Mime-Version: 1.0 (Apple Message framework v753.1)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <1BDBB0E5-CF8F-4DD6-BAA9-A300B6658907@bcs.org.uk>
Content-Transfer-Encoding: 7bit
From: David Muxworthy <d.muxworthy@bcs.org.uk>
Subject: Re: (SC22WG5.4222) What shall we do with the broken feature?
Date: Wed, 17 Mar 2010 13:27:34 +0000
To: sc22wg5@open-std.org
X-Mailer: Apple Mail (2.753.1)
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

On 17 Mar 2010, at 08:19, Malcolm Cohen wrote:

> How should we address the problem?
> (1) fix the DIS by deleting the feature (I don't think we have a  
> mandate for that though);
> (2) fix the DIS by changing the wording;
> (3) leave it to be fixed later via interpretation processing (other  
> than the nitpick which should be done anyway).
>
> Comments?

If there is a good chance that the problem could be fixed at the June  
J3 meeting (by either (1) or (2)) I would vote for doing that and  
having the resulting document checked by the four wise men again.   
The same could apply to any minor technical problem thrown up in the  
current ballot on N1814.  This would delay the standard by four  
months but, apart possibly from attracting the disapprobation of  
SC22, in practice it matters not a jot whether the standard hits the  
bookshops in 2010 or 2011.  I wouldn't want to get into a F8X-style  
slippage of schedules however.
David