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

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I think we are talking past each other.  There is no question that we are
relying on the PKWare Application Note.  No one seems to be disputing that.

But you make the very point that I think is a concern at JTC1.

We rely on the AppNote as a normative reference.

Yet, the AppNote lacks normative language and has no conformance classes or
clauses.  It is barely a specification and there are clear areas of
underspecification that matter in the case of interoperable documents.

Furthermore, if there were to be a JIRA issue against the ZIP Application
Note, where is there a jurisdiction for resolving that issue?  Certainly not
us, but who?  What is the maintenance body, what is its governance, and how
can one submit a defect report?

I submit that the success of Zip as a format is not attributable to the
quality of the AppNote but to the degree to which implementations are
interoperable to the extent they are relied upon in the internal integration
of document-format supporting software implementations.  (I also note with
interest that 7Zip suggests their unique compression method is superior and
should be used in favor of those provided for in the PKware App Note.)

That is not the same as having an agreed, open specification that can be
relied upon as a normative source in the way that JTC1 would prefer to see
normative dependencies supported and be sufficient for confirmable,
interoperable implementations.

 - Dennis

PS: Of course, there can be JIRA issues against how our reliance on the
AppNote might be underspecified or have other defects.  Those might devolve
into concerns about where the AppNote is itself not helpful for resolution.
Round-and-round.

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Friday, June 04, 2010 11:48
To: dennis.hamilton@acm.org
Cc: office@lists.oasis-open.org
Subject: RE: [office] SC34 Ballot N1414 "New Work Item Proposal on Document
Packaging"

"Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote on 06/04/2010 
01:36:31 PM:

> 
> The proposal acknowledges that it is about existing technology on which
> standards depend and which is in broad use, but there is no 
International
> Standard or equivalent on which other specifications can rely.
> 

I'd question that assertion.  We "rely" on the ZIP Application Note.  So 
does OOXML.  So does EPUB. And so do, implicitly, most of our ODF 
implementations, who use ZIP libraries from their programming platforms 
that themselves are based on the ZIP Application Note. This seems to be 
working fine.   The world has not ended the last time I looked out the 
window.  In particular I don't see any JIRA defects related to the 
contents of the Application Note.

> It also appears that the scope is limited to precisely a subset that 
works
> for document packaging as commonly relied upon as a substrate for IS 
26300,
> IS 29500, etc.  It is also proposed to deal with the case of packages 
that
> carry XML documents as components of some sort of connected composite
> structure and also standardize an use of Unicode in package information
> (something not established by the Zip specification on which we and 
others
> rely).
> 

Again, do we have a problem here?  We have our packaging specification. So 
does OOXML.  So does EPUB.  If we really wanted to attempt a harmonization 
here (and I'm open to this idea) I think we'd start by involving these 
three committees in a discussion.  And if we did that and made a list of 
issues that would need to be resolved to achieve that harmonization, I'd 
bet you that standardizing ZIP would not figure in the top 20 issues that 
would need to be resolved.  It is simply not a real world issue.

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.  This leads to problems when one part of the market is 
beholden to a group of experts in an entirely different technology.  You 
should match the standard to how the market treats the technology.  And 
for 20 years the market has clearly treated ZIP packaging/compression as a 
standalone concern.

-Rob

>  - Dennis
> 
> -----Original Message-----
> From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
> Sent: Friday, June 04, 2010 08:21
> To: office@lists.oasis-open.org
> Subject: [office] SC34 Ballot N1414 "New Work Item Proposal on Document
> Packaging"
> 
> 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.
> 
> [ ... ]
> 
> 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 
> 


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