SC34 Ballot N1414 "New Work Item Proposal on Document Packaging"

[robert_weir@us.ibm.com]

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.

====

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