[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: SC34 Ballot N1414 "New Work Item Proposal on Document Packaging"
I'd like to draw the TC's attention to the following ballot in JTC1/SC34: http://www.itscj.ipsj.or.jp/sc34/open/1414.pdf For the record I'd like to state that although we are clearly a stakeholder, the OASIS ODF TC was not consulted on this proposal, nor have we discussed it as a TC, nor have we given our approval to it. I've heard from some SC34 participants that they thought we supported this proposal, since the proposal states, "SC 34 has had strong indications from its experts and liaisons that a standardized, ZIP-compatible Document Packaging format would be of immense value". However, as stated above, the "strong indications from liaisons" apparently did not extend to consultations with this TC. And unless I missed something, this was not discussed in SC34/WG6 either. ODF 1.2 refers to the ZIP Application Note hosted by PKWARE. I believe OOXML does as well. I did a quick scan of JIRA and I don't see any unresolved ODF issues or defect reports that relate to the contents of the ZIP Application Note. There are some issues related to the stability of the URL to the specification, but I think we've resolved that now. == Rob's personal opinion == I don't think this proposal accurately reflects the way ZIP is used today in the market. There is ZIP as a generic packaging format. And then there is ZIP-based XML document formats. You don't want to mix the specifications of both of these into the same standard. Otherwise it is like specifying Unicode and XML together in the same standard. Sure, you could do it. But you then are doing something suboptimal for all the uses of Unicode that do not involve XML. There are good reasons why we don't have a single standard called "The Web". In this case the market for ZIP standalone is far larger than the market for ZIP-based XML document packaging. So you really want these to be separate standards. It is also not clear what real problem this proposal would address.From my experience with plugfests, OIC TC work and with ODF users and customers, I have never seen an interoperability problem related to ODF using ZIP. Has anyone? If anything, the ZIP portion of ODF is the most interoperable part of the entire standard! If someone in SC34 has spare cycles and wants to make a standard of legacy conventions that would truly benefit ODF (and OOXML and HTML and XSLT:FO and so on) then I'd recommend making a standard to describe calendars, date formats, text representation of numbers, Roman numerals, numeration conventions (for numbered lists), etc. These are social-linguistic conventions where ISO could truly make a contribution by enumerating these conventions, giving them identifiers and specifying their behaviors. So, I don't see where this SC34 ZIP proposal would benefit us in any immediate way. At best it simply repackages the specification we already have. At worst it diverges from what is supported from ODF editors and ZIP tools today. I'm not sure the downside from forking the specification (including introducing interoperability concerns into an area of the market which is not having interoperability problems) justifies the meager benefits. ==== Although as liaisons we cannot vote, the ODF TC can certainly submit comments in response to this ballot. Let me know if anyone has strong opinions on this proposal. If we can arrive at a position that the TC agrees with, we can submit it. Deadline is mid-July, I think. Regards, -Rob ------------- Rob Weir Co-Chair OASIS ODF TC
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]