My action item: Letter to the W3C Web Applications WG

[Innovimax SARL]

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 €
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20091030/c4987a79/attachment.htm>