My action item: Letter to the W3C Web Applications WG

[Rick Jelliffe]

MURATA Makoto (FAMILY Given) wrote:
>> 2) We accept to have many specification but we ask them to try to avoid
>> mecanism that forbide merging two or more package type into one
>>     
>
> OPC has interleaving.  Should it be dropped? 
>   
> OPC provides digital signature, and widget packages also provide 
> digital signature.  The mechanisms are apparently different.  Should 
> they be dropped or unified?
>   
> OPC uses %HH for non-ASCII part names.  Meanwhile wiget packaging uses 
> a recent version of the ZIP spec, which provides UTF-8 part names.  
> Should either OPC or widget packaging be changed?
>   
I think there are two issues:

1) Would the presence of a feature necessarily prevent merging?  I.e. 
are there some OPC files which can also be Widgets?

In the case of interleaving, interleaving is optional so availability of 
the feature in the specification would not prevent merging. In any case, 
interleaving is at the physical item level (files) so even if used it 
would not prevent merging.

In the case of digital signatures, they are optional so again the 
availability of the feature in the specification would not prevent 
merging. The OPC digital signatures uses OPC parts and relationships and 
so has name independence. So even if it is used, it would not prevent 
merging (i.e. even parallel signatures under both specifications).

In the case of %HH, yes, I think it would be useful for OPC to support 
UTF-8 or for Widgets to support %HH, or even both. This seems exactly 
the kind of gratuitous, coin-toss incompatibility that our standards 
should be addressing.

2) What possibilities are there for using the same packaging system for 
equivalent functions?

In the case of Interleaving, it may be the kind of thing that Widgets 
may be interested in at a future time, if there is need.  Widgets do not 
seem to have a strong need for updating internal data, however the need 
for rapid access to data being streamed in may be useful: the model here 
is streaming PDF, where the stream is in page chunks the stream can be 
reset forward or backwards to get particular pages fast.

In the case of digital signatures, both Widgets and OOXML use versions 
of the W3C Dig Signatures, so there is certainly scope for co-operation. 
And given that digital signatures are perhaps implemented like a CODEC 
system, where multiplicity is the norm, the flexibility in supporting a 
small number of mechanisms may be what implementers anticipate.

Since both use Unicode, the encoding is an issue of "lexical space" 
rather "value space". So as I mention above, it seems exactly the kind 
of gratuitous, coin-toss incompatibility that our standards should be 
addressing.

Cheers
Rick