OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [office] SC34 Ballot N1414 "New Work Item Proposal on Document Packaging"


Dave Pawson <dave.pawson@gmail.com> wrote on 06/05/2010 03:44:27 AM:

> 
> Re: [office] SC34 Ballot N1414 "New Work Item Proposal on Document 
Packaging"
> 
> On 4 June 2010 21:21, Thorsten Behrens <tbehrens@novell.com> wrote:
> 
> > Surely the work item proposal asks for an _independent_ standard? Or
> > am I getting you wrong here?
> 
> No, that is the focus of the work. Wouldn't expect Rob to have
> understood that, but it is key.
> 
> "... how is it possible to readily create a perfectly interoperable
> version of ZIP without infringing PKWARE's copyright? For all these
> reasons it seems that the proposal brings the risk of a legal
> challenge."
> 
> That is just a little key to this.
> 


I think I've been perfectly consistent on this.  I do not favor taking a 
single vendor's technology and turning it into an ISO standard.  I was 
quite vocal about this during the OOXML process.  If it is necessary to 
reference a legacy specification -- and I admit that there is sometimes a 
need to do this -- then there are better ways of handing this, including 
using the Referenced Specification (RS) process of JTC1 Directives Annex 
N. 

We should reserve the label of "standard" for specifications that are 
negotiated through a multi-party, deliberative open committee process.  We 
debase the name "standard" and "ISO" if we throw it around 
indiscriminately. 

As we saw from the OOXML process, if we take a legacy specification and 
try to adopt it unchanged, then the NBs are not happy and vote against it. 
 But if we approve the legacy specification with changes (as did 
eventually happen with OOXML) we end up with a standard that diverges from 
actual industry practice.  Neither outcome is desirable.  And note that in 
that case the standard was created with the participation of the author of 
the specification and primary implementers.  Imagine doing the same 
without the participation of the specification owner and vendors, as is 
being proposed for ISO ZIP.

Instead I'd point to the recent work in SC34 around CJK features for ODF 
and OOXML.  Did they start by proposing an NP and without consulting the 
stakeholders?  No.  They started with announcing a mini-conference to 
discuss the issues and invited all stakeholders.  They then wrote up a 
report of requirements and solicited feedback.  They now are discussing in 
the WG's, including WG, what is the best way to go forward with these 
requirements.  We'll probably end up with one or more NPs or Project 
Subdivisions from this effort, but by soliciting stakeholder involvement 
from the start, these motions will likely be uncontroversial and lead to 
more successful standards deliverables.

That is the way to do it.  We've had the ZIP Application Note for over 20 
years now.  Where is the special urgency to standardizing it that 
necessitates bypassing stakeholder consultations?  For example, why were 
WG4 and WG6 never consulted on this proposal?  Why was it introduced at 
the Stockholm SC34 Plenary without any prior notice?  Initially, NBs were 
asked to vote on the NP ballot motion without even seeing the text of the 
proposal.  It wasn't until I asked the Chairman to at least show us what 
we were voting on that NBs were giving 10 seconds to review the proposal, 
but still without opportunity to consult with their delegations.  This is 
all very irregular.

-Rob


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]