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 Document Packaging"

My reading of the deliverables, and the additional provisions (dealing with Unicode and addressing the use of cross-referencing XML document entities) is that it should be possible to substitute a normative reference to the proposed deliverable in, say, ODF-next, and there would be no harm and no foul and no practical issue with regard to upward/backward compatibility although some adjustment to current Zip profiling could be required.  Ideally, it would also be possible for PKWare to ground future Appnotes as (extending) profiles of the IS, if they so choose.

I disagree that one can make interoperable complete implementations from the Powered APPNOTE, which is not anywhere close to a sufficient specification.  The degree there is interoperability is the degree to which interoperable implementations have been achieved by other means.  The other means is pretty dodgy, providing nothing that can be profiled in some grounded way.  Waving at the PKWare APPNOTE and then going about ones business does not an interoperable specification make at the level of care and precision that befits an International Standard.

If this is seen as misappropriating anything of PKWare's, I think they are fully able to speak for themselves in the matter.

 - Dennis

 - - - - - MORE FUEL FOR THE FIRE - - - -

I am going to mention IS 29500 in this context, because it contains a remarkable demonstration of what it takes to create an interoperable profile of the PKWare APPNOTE for document packaging purposes.  In ISO/IEC 29500-2:2006 *Normative* Annex C, it takes 11 pages of concise tables to wrestle a well-delimited interoperable case to the ground.  This is just about Zip and nothing about how it is then used in the Open Packaging Conventions.  It says nothing that could not be adopted by reference in ODF 1.2 Part 3, for example, since it does not deal with what is carried in the Zip, just what is used of Zip itself.  In addition to Annex C, Annex G considerations apply to Zip (which is a special case for OPC purposes).  There are 25 conformance clauses applicable to Zip (sometimes in relationship to OPC-specific material carried in the Zip) that are extracted in Appendix section H.3. 

Finally, much to the surprise of many users of particular Zip archiving tools, they were unable to accept or use the OPC-allowed use of Padding which is allowed to support certain performance optimizations.  It was a common missing feature of the library implementations or utilities being used.  It is permissible to ignore the provision, but the consumer must pass over its occurrences properly.  


I find it remarkable that we have not, in all this time, taken a clue from this work in OPC.  I am sure there are many reasons why such deliberateness is seen as excessive or unnecessary or maybe even inadequate.  I suppose that is where folks disagree on what makes for an adequate specification and whatever its connection is to achieved interoperability.  

If we should have any concern for the work being undertaken at ISO/IEC JTC1 [SC34] perhaps the proper feedback is our expression of concern for how well the proposed deliverable would be usable as a substitute in our specifications in a way that preserved any upward/backward-compatibility of documents and that could be easily incorporated.  Ideally, it would relieve us from having to something as comprehensively thorough on our own, something it is not clear we have the expertise (and will) for, whether or not JTC1 can scare it up. 

-----Original Message-----
From: Patrick Durusau [mailto:patrick@durusau.net] 
Sent: Sunday, June 06, 2010 03:51
To: office@lists.oasis-open.org
Subject: Re: [office] SC34 Ballot N1414 "New Work Item Proposal on Document Packaging"


[ ... ]

Then, the deliverables of the project:

> • Specification of a minimal compressed archive format suitable for 
> immediate use with the
> document standards named above
> • Specification of XML serializations of archive data for validation 
> purposes
> • Specification of a mechanism for exposing archived document 
> structure, when those archived
> documents are XML

Err, now we are at: "specification of a minimal compressed archive 
format suitable for immediate use...."

So, it could mean:

1) Standardize the poor non-standardized (but apparently used as a 
standard) ZIP format. ;-)

2) Standardize some minimal sub-set of the ZIP format.

3) Standardize some "minimal compressed archive format" for use with:

> • ISO/IEC 26300 (Open Document Format for Office Applications)
> • ISO/IEC 29500 (Office Open XML)
> • EPUB ( standardized by The International Digital Publishing Forum 
> http://www.idpf.org/ )
> • W3C Widget Packaging and Configuration
> • ADL SCORM ( http://www.adlnet.gov/Technologies/scorm/ )

[ ... ] 

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