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 DocumentPackaging"

Thorsten Behrens <tbehrens@novell.com> wrote on 06/04/2010 04:21:37 PM:

> you wrote:
> > I'm not saying that there are not interesting things that could be 
> > standardized here.  For example, it might be nice to have a standard 
> > protocol for ZIP, or standard fragment schema for URL addressing of 
> > items, etc.  Or any other conventions that are effectively a layer 
> > core ZIP's compression/packaging specification and what ODF/OOXML/EPUB 

> > use.  But including the core ZIP packaging/compression in the same 
> > standard is a real bad idea, IMHO.  As I said before, it is like 
> > specifying Unicode and XML in the same standard.  Or XML and ODF in 
> > same standard.
> >
> Surely the work item proposal asks for an _independent_ standard? Or
> am I getting you wrong here?
> I otherwise tend to agree with Dennis, there's merit to have
> properly standardized what we're referencing, instead of reliance on
> single-vendor goodwill ...
> Cheers,

My view is that the benefits of standardization come from the process of 
standardization, not merely by giving the stamp of "standard" to a 
specification.  The rigor of a committee process, the lengthy review, the 
implementation experience -- all this improves the specification so by the 
time it is a standard it is of improved quality and more suitable for 
broad use.  Calling something a standard does not improve it.  But the 
standardization activity may improve it.

However, standardization is not the only activity that can be used to 
improve a specification.  I'd argue it is one of the most efficient ways 
of doing it, but I would not claim that standardization has some magical 
exclusive ability to improve technical specification.  In the ZIP case I'd 
assert they have achieved a level of maturity that equals or exceeds your 
typical ISO standard.  Remember, the ZIP Application Note has been around 
since 1989.  It is older than OASIS.  It is older than the W3C.  I suspect 
it is older than SC34.  At this point he tangible benefit of standardizing 
it seems minuscule at this point.

And note that there is nothing irregular about an ISO standard using 
external specifications as normative references.  See JTC1 Directives, 
Annex N.  There is a procedure for JTC1 to review and approve the use of 
external specifications, what are called "Referenced Specifications". 
Since we are currently referencing ZIP in ODF 1.2, we'll likely trigger 
the Annex N provisions when we submit ODF 1.2 to ISO.  At that point JTC1 
will approve or disapprove our use of ZIP as a Referenced Specification. 
If it does approve it, as I assume it will, then the SC34 proposal will be 

As I said before, I believe the proponents of this proposal have attacked 
the problem from the wrong end.  Starting with a proposal for a new 
standard is premature.  They really need to start with talking to the 
relevant stakeholder committees and see what the practical opportunities 
for harmonization are, and get agreement to work toward that.  Assuming 
that you already know the answer, without talking to any of the 
stakeholders, is always the wrong approach.  The creation of a new 
standards project comes at the end of a process of getting stakeholder buy 
in.  To do it in the other direction is like renting a wedding hall, 
hiring a band, getting fitted for a tuxedo, sending out invitations and 
only then looking for a bride.  It won't work.  Next time, try starting 
with a kiss ;-)


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