[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 <email@example.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 <firstname.lastname@example.org> 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