My action item: Letter to the W3C Web Applications WG

Fri Oct 30 08:23:10 CET 2009

Well

I have to precise what I understood from Rick

My understanding is that Harmonization could be interpreted in at least two
ways :

1) We try to have one specification for all package

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

I'm not in favor of the 1) for the reason Murata san clearly said in its
first draft

But I'm clearly in favor of the 2) if we can. There is one very big issue
with 2) about MIME-TYPE. It will be hard to harmonize on that unless we
agree on something we discussed in Seattle (+zip +opc +wpc combination).
They will have the same problem as (+xml) but then if we don't forbid
merging then we could think of providing combination MIME-TYPE
(application/combozip+opc+wpc)

The same way we could think of having the ability to merge ODF and OOXML as
well as merging two OOXML (DOCX and XLSX) document in one

Mohamed

On Fri, Oct 30, 2009 at 8:02 AM, Innovimax SARL <innovimax at gmail.com> wrote:

> Rick,
>
> +100 " An OOXML document that also can load in as a W3C Widget seems an
> interesting new delivery mechanism for OOXML."
>
> It could be a work item to SC 34 to work on those king of harmonisation
> with ZIP-like package and I would be interested in participating
>
> Mohamed
>
>
> On Fri, Oct 30, 2009 at 7:54 AM, Rick Jelliffe <rjelliffe at allette.com.au>wrote:
>
>> MURATA Makoto (FAMILY Given) wrote:
>>
>>> Rick,
>>>
>>> Thank you for the comment, but I am afraid I do not quite understand it.
>>>
>>>
>>>
>>>> The most we would request at this stage is that the Widgets format would
>>>> avoid any unnecessary features that might prevent a Widget from
>>>> containing
>>>> a directly embedded IS 29500 (OOXML) or IS 26300 (ODF) file.
>>>>
>>>> The requirements for OOXML in this regard are merely to avoid using a
>>>> ZIP
>>>> part named _rels/.rels  and a ZIP part Content_Type.
>>>>
>>>>
>>>
>>> Are you saying that it should be easy to distinguish widget packages and
>>> OPC packages by examining some parts?  (If so, I understand your point.)
>>>  Or,
>>> are you saying that widget packages should be prohibited from having
>>> parts named _rels/.rels or Content_Type?  (If so, I do not understand.
>>>  Why?)
>>>
>>>
>> As you know, I think that "harmonization" is more likely to occur by
>> parallel alternatives rather than by a common single vocabulary. An OOXML
>> file that is also a website (WAR), for example.
>> There are already signs of this: for example, there are ODF files which
>> embed PDF pages, the use of MathML as well as OMath, and in fact the Open
>> XML MCE system is based on parallel alternatives.  An OOXML document that
>> also can load in as a W3C Widget seems an interesting new delivery mechanism
>> for OOXML.
>>
>> AFAICS all that is necessary or possible at this stage is to make sure
>> that this kind of file format mashup is not precluded by some dumb technical
>> choice made now. So the more that the same low-level conventions w.r.t. ZIP
>> subset, UTF-8 usage, URL scheme, part-to-name, and name clashes are used,
>> the better.  But I recognize that this is somewhat outside the scope or
>> logistics of WG4 proper.
>>
>> So I think a more pro-active statement would be appropriate. I would
>> suggest:
>>
>> --------------------------------------------------------------------
>> Dear W3C Web Applications WG,
>> I am writing on behalf of ISO/IEC JTC1/SC34/WG4, which is responsible for
>> the maintenance of ISO/IEC 29500 (OOXML).
>>
>> WG4 reviewed the working draft "Widgets 1.0: Packaging and
>>
>> Configuration" with interest.  It provides a package format similar to
>> the OPC(Open Packaging Conventions), which is specified in ISO/IEC
>> 29500-2.*
>>
>> There are several current standards efforts which use an XML-in-ZIP
>> format. In particular SC34, WG4 maintains OPC, and WG6 is expected
>> to be processing the ODF 1.2 Part 3 Packaging specification in the
>> new year for an update to ISO/IEC 26300. At the ZIP, part name and URL
>> levels, there are many commonalities.
>> WG4 believes that widget packages and OPC packages are meant to meet
>> different requirements, and thus they could not be unified in a hurry.
>>
>>
>> Requirements specific to OPC include file renaming and
>> fallback-guaranteed extensibility through ISO/IEC 29500-3 (Markup
>> Compatibiity and Extensions).  Meanwhile, those specific to widgets
>>
>> packages include start files, icon files, localization, and
>> preferences among others.
>>
>> Nevertheless, WG4 believes that there are quite a few similarities
>> between widget packages and OPC packages, and that information
>> exchange between the W3C Web Applications WG and WG4 would be very
>> fruitful.
>> The following are three possibilities:
>>
>> 1) Some members of WG4 intend to join a public
>>
>> mailing list for the discussion of a scheme for package URIs, namely <
>> http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/>.
>>  Note that OPC has a package URI format: the "pack" scheme.
>>
>> 2) The OPC specification may be a useful source of ideas, terms, phrases
>> and references for the Widgets specification, notably in areas such as the
>> ZIP subset, part concept, the part-to-name mapping, the pack scheme and
>> UTF-8 usage. We commend these to the Web Applications WG.
>>
>> 3) Reducing gratuitous differences may serve the interests of the public
>> and developers and allow future mashed-up document formats, for example the
>> delivery of OOXML and ODF documents as W3C Widgets.  In concrete terms, OPC
>> only reserves two file names: /_rels/.rels and  /[Content_Types].xml   The
>> current Widgets working draft  does not use or preclude these, so we see no
>> name clash that might require action.
>>  JTC1/SC34/WG4 looks forward to your views on this matter.
>>
>> Regards,
>>
>> SC34/WG4 Convenor
>> MURATA Makoto (FAMILY Given)
>>
>> * The text of the OPC specification as available from ECMA as
>> ECMA 376 Part 2 (Second Edition) <
>> http://www.ecma-international.org/publications/standards/Ecma-376.htm>
>> and from the public ISO Website.
>>
>> -------------------------------------------------------------------
>>
>>
>
>
> --
> Innovimax SARL
> Consulting, Training & XML Development
> 9, impasse des Orteaux
> 75020 Paris
> Tel : +33 9 52 475787
> Fax : +33 1 4356 1746
> http://www.innovimax.fr
> RCS Paris 488.018.631
> SARL au capital de 10.000 €
>

-- 
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 9 52 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20091030/4c56ca68/attachment.htm>