Well <br><br>I have to precise what I understood from Rick <br><br>My understanding is that Harmonization could be interpreted in at least two ways :<br><br>1) We try to have one specification for all package<br><br>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<br>
<br>I'm not in favor of the 1) for the reason Murata san clearly said in its first draft<br><br>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)<br>
<br>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 <br><br>Mohamed<br><br><div class="gmail_quote">On Fri, Oct 30, 2009 at 8:02 AM, Innovimax SARL <span dir="ltr"><<a href="mailto:innovimax@gmail.com">innovimax@gmail.com</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;">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<div><div></div><div class="h5"><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" target="_blank">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>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>
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><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><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><br>
packages include start files, icon files, localization, and<br>
preferences among others.<br>
<br></div><div>
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><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>
JTC1/SC34/WG4 looks forward to your views on this matter.<br>
<br></div><div>
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></div></div><div><div></div><div class="h5">-- <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" target="_blank">http://www.innovimax.fr</a><br>
RCS Paris 488.018.631<br>SARL au capital de 10.000 €<br>
</div></div></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>