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

[Bob Jolliffe <bobjolliffe@gmail.com>]

Hi Rob

On 4 June 2010 16:21,  <robert_weir@us.ibm.com> wrote:
> I'd like to draw the TC's attention to the following ballot in JTC1/SC34:
> http://www.itscj.ipsj.or.jp/sc34/open/1414.pdf
>
> For the record I'd like to state that although we are clearly a
> stakeholder,  the OASIS ODF TC was not consulted on this proposal, nor
> have we discussed it as a TC, nor have we given our approval to it.
>
> I've heard from some SC34 participants that they thought we supported this
> proposal, since the proposal states, "SC 34 has had strong indications
> from its experts and liaisons that a standardized, ZIP-compatible Document
> Packaging format would be of immense value".  However, as stated above,
> the "strong indications from liaisons" apparently did not extend to
> consultations with this TC.  And unless I missed something, this was not
> discussed in SC34/WG6 either.
>
> ODF 1.2 refers to the ZIP Application Note hosted by PKWARE.  I believe
> OOXML does as well.  I did a quick scan of JIRA and I don't see any
> unresolved ODF issues or defect reports that relate to the contents of the
> ZIP Application Note.  There are some issues related to the stability of
> the URL to the specification, but I think we've resolved that now.
>
> == Rob's personal opinion ==
>
> I don't think this proposal accurately reflects the way ZIP is used today
> in the market.  There is ZIP as a generic packaging format.  And then
> there is ZIP-based XML document formats.  You don't want to mix the
> specifications of both of these into the same standard.  Otherwise it is
> like specifying Unicode and XML together in the same standard.  Sure, you
> could do it.  But you then are doing something suboptimal for all the uses
> of Unicode that do not involve XML.
>
> There are good reasons why we don't have a single standard called "The
> Web".
>
> In this case the market for ZIP standalone is far larger than the market
> for ZIP-based XML document packaging.  So you really want these to be
> separate standards.
>
> It is also not clear what real problem this proposal would address.From my
> experience with plugfests, OIC TC work and with ODF users and customers, I
> have never seen an interoperability problem related to ODF using ZIP.  Has
> anyone?   If anything, the ZIP portion of ODF is the most interoperable
> part of the entire standard!
>
> If someone in SC34 has spare cycles and wants to make a standard of legacy
> conventions that would truly benefit ODF (and OOXML and HTML and XSLT:FO
> and so on) then I'd recommend making a standard to describe calendars,
> date formats, text representation of numbers, Roman numerals,  numeration
> conventions (for numbered lists), etc.  These are social-linguistic
> conventions where ISO could truly make a contribution by enumerating these
> conventions, giving them identifiers and specifying their behaviors.
>
> So, I don't see where this SC34 ZIP proposal would benefit us in any
> immediate way.  At best it simply repackages the specification we already
> have.  At worst it diverges from what is supported from ODF editors and
> ZIP tools today.  I'm not sure the downside from forking the specification
> (including introducing interoperability concerns into an area of the
> market which is not having interoperability problems) justifies the meager
> benefits.
>

I don't think I really agree with yourself and Patrick over either the
non-desirability or the pointlessness of this new work item.  Besides
your point about stakeholder consultation, that is.  Clearly we are
stakeholders and should be consulted.

But there are at least two issues about our current reliance on the
appnote which concern me:

1.  there are worrying grey areas over the IP "arrangements" on offer
to implementors.  In particular we find ourselves forever skipping
lightly around problems like the "native" zip encryption and
signatures.  Of course there is absolutely no guarantee that an ISO
standard should be possible to implement royalty-free, but it does
seem to me that there is an opportunity while defining minimum
features, that we can make strong recommendations and clear
requirements that might put implementors on a surer footing.

2.  whereas I would be the first to acknowledge that pkware has been a
good and wise citizen in the way it has promoted and laid open the zip
format, we all know that companies and their web sites come and go.
Having an independently maintained specification - ie one that is not
subject purely to the whim of a single vendor - remains an incredibly
important piece of the open standards and interoperability rubric.  It
is not in my view a principle which can be raised or lowered depending
on a subjective evaluation of the good or bad intentions or history of
the vendor concerned.

If this proved to be a fork of the current zip specification that
would be unfortunate.  In terms of stakeholder involvement I can only
assume that pkware have been invited to contribute, but perhaps not.

Whether there is a sufficient amount of the right competence within
JTC1/SC34 to do this work isn't something that would concern me much.
If there is sufficient perceived need for the work to go forward I
imagine the resources will follow.  If not it will fail.  There's
certainly been enough implementations of compression and archiving
libraries by enough vendors and independent implementors that I can't
believe there is a scarcity.  I would have greater doubts about
JTC1/SC34 being the natural home for such a specfication because of
(i)   the sometimes glacial processes involved, and
(ii)  the fact that ISO/JTC1 may not address my IP concern robustly, and
(iii) the perception and reality of vendor-neutrality of process
within ISO suffered a serious credibility knock over 29500.

But if there is a new work item on the table, as it appears there is,
and some preliminary work has already been done, I would like to see
our stakeholder input being used to drive some clear requirements
around (ii) and (iii).  I might prefer that this work was taking place
within OASIS, W3C or IETF but I guess that isn't up to me.

Patrick, I am not really swayed by the suggestion that this is some
sort of raid on the company's property.  If anything the reverse would
be true.  For me the matter of separating out, as well as is possible,
subject matter which is not subject to pkware (or anyone else's) IPR
claims is critical.  Referring to the whole bundle of ideas as the
company's property is a form of reification of property relations
which I don't buy into.  Plagiarism on the other hand would concern me
greatly.

Regards
Bob


> ====
>
> Although as liaisons we cannot vote, the ODF TC can certainly submit
> comments in response to this ballot.  Let me know if anyone has strong
> opinions on this proposal.  If we can arrive at  a position that the TC
> agrees with, we can submit it.  Deadline is  mid-July, I think.
>
> Regards,
>
> -Rob
>
> -------------
> Rob Weir
> Co-Chair OASIS ODF TC
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>