Thorsten Behrens <> 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
URL
> > protocol for ZIP, or standard fragment schema for URL addressing of
ZIP
> > items, etc. Or any other conventions that are effectively a layer
between
> > 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
the
> > 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
irrelevant.
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 ;-)
-Rob
