Rick,<br><br>+100 " An OOXML document that also can load in as a W3C Widget seems an interesting new delivery mechanism for OOXML."<br><br>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<br>
<br>Mohamed<br><br><div class="gmail_quote">On Fri, Oct 30, 2009 at 7:54 AM, Rick Jelliffe <span dir="ltr"><<a href="mailto:rjelliffe@allette.com.au">rjelliffe@allette.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5">MURATA Makoto (FAMILY Given) wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Rick,<br>
<br>
Thank you for the comment, but I am afraid I do not quite understand it.<br>
<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The most we would request at this stage is that the Widgets format would<br>
avoid any unnecessary features that might prevent a Widget from containing<br>
a directly embedded IS 29500 (OOXML) or IS 26300 (ODF) file.<br>
<br>
The requirements for OOXML in this regard are merely to avoid using a ZIP<br>
part named _rels/.rels and a ZIP part Content_Type.<br>
<br>
</blockquote>
<br>
Are you saying that it should be easy to distinguish widget packages and<br>
OPC packages by examining some parts? (If so, I understand your point.) Or,<br>
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?)<br>
<br>
</blockquote></div></div>
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. <br>
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.<br>
<br>
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.<br>
<br>
So I think a more pro-active statement would be appropriate. I would suggest:<br>
<br>
--------------------------------------------------------------------<br>
Dear W3C Web Applications WG, <br><div class="im">
I am writing on behalf of ISO/IEC JTC1/SC34/WG4, which is responsible for the maintenance of ISO/IEC 29500 (OOXML).<br>
<br></div>
WG4 reviewed the working draft "Widgets 1.0: Packaging and<div class="im"><br>
Configuration" with interest. It provides a package format similar to<br>
the OPC(Open Packaging Conventions), which is specified in ISO/IEC<br></div>
29500-2.*<br>
<br>
There are several current standards efforts which use an XML-in-ZIP<br>
format. In particular SC34, WG4 maintains OPC, and WG6 is expected<br>
to be processing the ODF 1.2 Part 3 Packaging specification in the<br>
new year for an update to ISO/IEC 26300. At the ZIP, part name and URL<br>
levels, there are many commonalities. <br>
WG4 believes that widget packages and OPC packages are meant to meet<br>
different requirements, and thus they could not be unified in a hurry.<div class="im"><br>
<br>
Requirements specific to OPC include file renaming and<br></div>
fallback-guaranteed extensibility through ISO/IEC 29500-3 (Markup<br>
Compatibiity and Extensions). Meanwhile, those specific to widgets<div class="im"><br>
packages include start files, icon files, localization, and<br>
preferences among others.<br>
<br></div><div class="im">
Nevertheless, WG4 believes that there are quite a few similarities<br>
between widget packages and OPC packages, and that information<br>
exchange between the W3C Web Applications WG and WG4 would be very<br>
fruitful. <br></div>
The following are three possibilities:<br>
<br>
1) Some members of WG4 intend to join a public<div class="im"><br>
mailing list for the discussion of a scheme for package URIs, namely <<a href="http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/" target="_blank">http://lists.w3.org/Archives/Public/public-pkg-uri-scheme/</a>>.<br>
</div>
Note that OPC has a package URI format: the "pack" scheme.<br>
<br>
2) The OPC specification may be a useful source of ideas, terms, phrases<br>
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.<br>
<br>
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. <br>
<div class="im">
JTC1/SC34/WG4 looks forward to your views on this matter.<br>
<br></div><div class="im">
Regards,<br>
<br>
SC34/WG4 Convenor<br>
MURATA Makoto (FAMILY Given)<br>
<br></div>
* The text of the OPC specification as available from ECMA as<br>
ECMA 376 Part 2 (Second Edition) <<a href="http://www.ecma-international.org/publications/standards/Ecma-376.htm" target="_blank">http://www.ecma-international.org/publications/standards/Ecma-376.htm</a>><br>
and from the public ISO Website.<br>
<br>
-------------------------------------------------------------------<br>
<br>
</blockquote></div><br><br clear="all"><br>-- <br>Innovimax SARL<br>Consulting, Training & XML Development<br>9, impasse des Orteaux<br>75020 Paris<br>Tel : +33 9 52 475787<br>Fax : +33 1 4356 1746<br><a href="http://www.innovimax.fr">http://www.innovimax.fr</a><br>
RCS Paris 488.018.631<br>SARL au capital de 10.000 €<br>