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"


Dave,

On 6/6/2010 2:05 AM, Dave Pawson wrote:
> On 5 June 2010 17:51,<robert_weir@us.ibm.com>  wrote:
>    
>> Dave Pawson<dave.pawson@gmail.com>  wrote on 06/05/2010 03:44:27 AM:
>>
>>      
>>> Re: [office] SC34 Ballot N1414 "New Work Item Proposal on Document
>>>        
>> Packaging"
>>      
>>> On 4 June 2010 21:21, Thorsten Behrens<tbehrens@novell.com>  wrote:
>>>
>>>        
>>>> Surely the work item proposal asks for an _independent_ standard? Or
>>>> am I getting you wrong here?
>>>>          
>>> No, that is the focus of the work. Wouldn't expect Rob to have
>>> understood that, but it is key.
>>>
>>> "... how is it possible to readily create a perfectly interoperable
>>> version of ZIP without infringing PKWARE's copyright? For all these
>>> reasons it seems that the proposal brings the risk of a legal
>>> challenge."
>>>
>>> That is just a little key to this.
>>>
>>>        
>>
>> I think I've been perfectly consistent on this.  I do not favor taking a
>> single vendor's technology and turning it into an ISO standard.
>>      
> I didn't think you understood it Rob.
> Read Thorstens email again.
>
>    

What part of Thorsten's email would you draw our attention to?

Thorsten wrote (his entire comment):

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

Reading the NP, it is difficult to see exactly what is being proposed 
(satisfy yourself in that regard, 
http://www.itscj.ipsj.or.jp/sc34/open/1414.pdf).

 From the NP:

> Scope: This proposal is for an International Standard that specifies a 
> minimal file format for combining
> multiple resources into a single resource (termed a “package”). Stored 
> resources are optionally
> compressed, and have some technical associated metadata, such as a 
> checksum. For packages in
> which stored resources are XML documents, the proposed standard shall 
> specify mechanisms by which
> such documents, and the relationships between them, may be exposed for 
> validation purposes.

Not clear what a "minimal file format" means but read on:

Annex A says (in part):

> One increasingly common approach is to specify formats in which XML 
> documents and other digital
> resources are stored together in an archive based on a minimal 
> implementation of what is known as the
> “ZIP” format.

....

> However, despite the widespread use of the ZIP format, it has never 
> been standardized.

> Such a pervasive format as ZIP would benefit greatly from being an 
> International Standard. In practice,
> formats using ZIP for document packaging use a small and 
> well-established subset of the overall current
> non-standard technology which can be quickly standardized. SC 34 has 
> had strong indications from its
> experts and liaisons that a standardized, ZIP-compatible Document 
> Packaging format would be of
> immense value, and wishes to ballot this NP to gather member body 
> feedback.

So, on one had, ZIP will benefit from being standardized (I would think 
it already is "standardized" since everyone is successfully using it but 
I digress.) and yet now we are talking about a "...small and 
well-established subset of the overall current non-standard technology...."

Hmmm, must mean non-standardized in the sense of no ISO stamp, not 
non-standardized in the sense of lack of interoperability.

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

In which case I don't know that it involves ZIP at all, perhaps this is 
the "independent" reading.

All realizing that compression is only one aspect of defining a 
packaging convention.

Even assuming reading #3, there is no common expertise in SC 34 for 
dealing with the compression aspects of a packaging specification.

Moreover, although I am hardly considered a capitalist by money grubbing 
capitalists, ;-), I do balk at simply appropriating a part of a vendor's 
core technology for standardization. Even if the vendor allows it to be 
freely used by others. (We could at least ask first.)

PKWare may not have all the trappings of a public service but they have 
done more to be of service to the software community (and the public) 
than many organizations I could name. As they say, "pretty is as pretty 
does."

Hope you are having a great weekend!

Patrick


-- 

Patrick Durusau
patrick@durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)

Another Word For It (blog): http://tm.durusau.net
Homepage: http://www.durusau.net
Twitter: patrickDurusau



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