EOOXML at JTC-1
- EOOXML issues (index page for EOOXML]]
- EOOXML objections (project draft document)
- EOOXML Contacts (National Standards Bodies to approach)
Draft objections that can be used by ISO/IEC JTC 1 "P" national bodies to object to: (i) fast track processing for the EOOXML proposed ISO standard; (ii) processing of the EOOXML proposal until such time as objections are resolved.
This project is collaborative. There are tasks that require expertise and those that do not. See the Tasks topic on this page. Your contributions are welcome.
Please work offline as much as is feasible. The outline is still under development and there is a risk of data being lost during entire page revisions.
What we want to look for in general are places where EOOXML falls short of what is required for interoperable, multi-vendor, multi-platform, multi-application, multi-language, multi-culture use. Ways in which this EOOXML may fall short of this may include:
- Under-specification -- If something is only partially specified, then other vendors will not be able to interoperate with this feature. For example, the EOOXML format does not appear to specify how macros or script are embedded in an EOOXML document. So not only is technical interoperability hindered, but Microsoft's Open Specification Promise grants developers rights if at all only to portions of the specification that are "described in detail and not merely referenced."
- Non-specification -- If something is merely labeled but no semantics are given, then it has not actually been specified.
- Example: "autoSpaceLikeWord95" (page 2161) merely defines semantics in reference to a legacy application whose behavior itself is nowhere specified. This contradicts Annex "A" of the "Rules for the structure and drafting of International Standards, which defines the "principle of verifiability" (A.4) "Whatever the aims of a product standard, only such requirements shall be included as can be verified."
- Platform dependencies -- This has two angles. You want to ask if there is something that can only be implemented on Windows. But also note features that are arbitrarily optimized for Windows with blatant disregard for equal access by competitors in the market.
- An example of the first kind of problem is 3.2.29 "Workbook Protection" (page 2698) defines an encryption algorithm by including several pages of C-language source code, code which appears to have byte-ordering dependencies and will produce different results on different machine architectures.
- Examples of the 2nd kind of problem include 22.214.171.124 "Clipboard Data" (page 5905) defines a schema type that can encode clipboard format values for Windows and the Macintosh, but doesn't seem to allow for other operating systems.
- Application dependencies -- Watch for places where EOOXML only considered the needs of Microsoft Office to the gross neglect of other vendors and applications which would naturally produce or consume word processor, spreadsheet and presentation documents.
- For example, 126.96.36.199 "Disable Features Incompatible with Earlier Word Processing Formats" (page 2252) explicitly states that it only considers the needs of Word 97-2003.
- Also, 188.8.131.52 "Disable Features Not Supported by Target Browser" (page 2120) is designed to optimize for various version of Internet Explorer and disregards entirely I.E.'s main competitor, Mozilla Firefox, as well as other alternative browsers.
- Poorly-designed XML -- We don't want to get into religious wars here arguing XML Schema versus RELAX NG. However, there are certain engineering standards and best practices regarding the use of XML where there is a broad consensus among experts and practitioners. We should list places where EOOXML violates this consensus.
- For example, 2.18.11 "Conditional Formatting Bitmask" (page 2478) requires the use of bitmasks. This is poor XML design because some of the standard XML processing tools like XSLT lack bitwise operators, making the use of this data impossible.
- Also, 3.17.4 "Date and Times" (page 3305-6) requires that spreadsheet dates treat the year 1900 as a leap year, which is incorrect in the Gregorian Calendar. This causes problems when interfacing with other tools and libraries which calculate dates correctly.
- The Naming conventions of XML Attributes, Child and Parent Elements betray the programming oriented nature of EOOXML. The naming conventions are thoroughly inconsistent throughout the specifications and this will cause significant frustration, confusion and increase implementation problems. Examples are the myriad Attribute naming conventions in 184.108.40.206 "settings(Document Settings)" (page 2020). Detailed explanation here: "EOOXML has poor XML Element names"
- Cultural Adaptability problems -- This encompasses issues with character sets, languages, calendars, currency symbols, numeric formatting, etc.
- For example, 220.127.116.11 "NETWORKDAYS" (page 3505) defines a spreadsheet function that calculates the number of days between two dates, ignoring weekends. This fails to account for different definitions of "weekend" in different cultures. In Islamic society, for example, the weekend may be Thursday/Friday or Friday/Saturday.
- Editorial issues -- including grammar, typographical errors, spelling errors, incorrect control language ("must" instead of "shall" for example). We probably don't want to spend too much time recording these kinds of errors.
Since we are dealing with a 6,000+ page specification, a keyword search approach is a valuable supplement or substitute for reading the specification.
Some suggested keywords to search for include:
bitmask, Windows, application-defined, legacy, binary, blob, base64, signature, encrypt, MSDN, Word, Excel,PowerPoint, Internet Explorer, SQL Server, SharePoint, might, compatible, undefined, OLE, DDE, COM, ActiveX, outside the scope, internal, SDK, .NET, device
The text of recurring guidance can also be used to locate sections that may pose similar problems. See e.g., the text of the EOOXML "guidance" notice reprinted in an article here.
Things that need doing, who is working on/coordinating them, the completion status of the task (Tasks summary subtopic) and task descriptions (Task descriptions subtopic). If you take on a task, please indicate that you have done so in the Tags summary section here so we don't duplicate efforts. Query, does MediaWiki have a facility for tracking tasks? Answer: No, not explicitly, no. Just creating a new page with a set of name + tasks seems enough to me, though.
- Outline -- Develop major writing outline for objections -- Marbux (mostly done, but evolving).
- Detailed comments -- develop detailed comments on the EOOXML specification
Detailed comments on EOOXML specification
This document will be an annex to the narrative document and should be formatted as a single table in OpenDocument ODT format.
|MB||EOOXML does not appear to specify how macros or scripts are embedded in an EOOXML document. So not only is technical interoperability between implementing applications hindered, but Microsoft's Open Specification Promise grants no rights to other developers to embed macros and scripts (rights granted only for portions of the specification that are "described in detail and not merely referenced").|
|2161||MB||"autoSpaceLikeWord95" merely defines semantics in reference to a legacy application whose behavior itself is nowhere specified. This contradicts Annex "A" of the "Rules for the structure and drafting of International Standards, which defines the "principle of verifiability" (A.4) "Whatever the aims of a product standard, only such requirements shall be included as can be verified."|
Note that the first example is a comment that refers to no particular page so its page number cell is left blank.
- Page -- Page number of the first page in the EOOXML specification to which the comment refers in 4-digit format (include leading zeros). Generally applicable comments such as the first example above should leave the Page cell blank. Page numbering is important not only for reviewer purposes but will allow us to sort all comments into page number order when the annex is complete. Important note: Cite only to PDF page numbers. The specification has two sets of page numbers, the pages numbers of the PDF file, and the page numbers from the original word processing document. The latter page numbers are ambiguous, since the PDF was created by appending multiple individual PDF files together. Section numbers are also repeated and therefore ambiguous; citing them could only induce (further) confusion.
- ID -- Initials or other short identifier allowing us to get back to you if there is a question.
- Deficiency -- the cell in which to place the narrative of your comment.
- Reserved -- A column for later reviewers to place their notes.
- EOOXML specification. Use this version, since it is the same as what JTC 1 sent out to members for review. All citations should be made by reference to the PDF page numbers (not the original document page numbers) of this version of the specification.
- You may also wish to cite to the following two ISO documents:
- ISO/IEC Directives, Part 2, "Rules for the structure and drafting of International Standards." This part specifies the correct format and structure and language required in an ISO specification
- JTC 1 Directives. This sets the policies for JTC 1.
- See also the general summary, EOOXML -- What is a 'contradiction' at ISO and what are its procedures? -- Updated.
This section for announcements, other communications, etc. If you don't know where to park information or a link, please use this section. If the section gets big, we'll move it to a separate page and link to it here.
??? Copyright issue: Isn't there an issue where graphical borders are coded by number, and so you have to violate copyright law to get the same border?
--Felix the Mac 19:58, 20 January 2007 (EST)
1. Why are there 2 GrokDoc pages for this project? They seem to overlap almost completely (like ODF and OOXML :-)
- One is for project coordination; the other is the document we are working on. --Marbux
2. How can people who are putting effort into this contact each other? (apart from this inbox)
- Please contact Pamela Jones using the mail link in the left column on the Groklaw site. -- Marbux
3. It seems to me that for maximum impact the objections need to be submitted by Monday 29th January. So if you are sending this by post that actually meeans Friday 26th January. The JTC1/SC34 web site has a long list of committee members who could be sent the objections at that point.
--Felix the Mac 12:45, 22 January 2007 (EST)
Apparently ANSI/INCITS are meeting from 23-25 January and will be discussing ECMA 376. Also the INCITS web site says that notification of perceived contradictions should be received by 20th Janaury. I believe that we need to send an email within the next 2-3 hours. There are many people who could do that better than me (especially since I am not as US citizen). Please update this Inbox to say who will handle that. If I don't hear anything then I will send an email at 20:00 UK time. Email should be sent to firstname.lastname@example.org amongst others.
DONE to email@example.com, firstname.lastname@example.org, email@example.com
--Felix the Mac 12:55, 22 January 2007 (EST)
Are there any objections to me sending an email similar to the Sample Letter on the EOOXML Contacts page to every organisation which has 'Liaison' staus with JTC1? (These organisations are also listed on that page)
--Felix the Mac 19:04, 22 January 2007 (EST)
In EOOXML objections, I really think you need to get rid of this phrase "It is extortion, pure and simple."
DONE - not suitable language for presentation to ISO
--Felix the Mac 20:24, 22 January 2007 (EST)
Would it be better to use 'ECMA 376' in place of 'Ecma 376'. Acronyms should be capitalized.
(or even 'ECMA-376' since ECMA themselves use a hyphen)
--Felix the Mac 20:32, 22 January 2007 (EST)
Unfortunately JTC 1 is not supposed to be hyphenated. Should this be fixed?
For consistency, the following terms are used in drafting the document. Do not worry about spelling out the term. The document will be edited to do so consistently before it is finished.
- EOOXML -- Use this abbreviation for the Ecma-376, Ecma Office Open XML, the official name of the Ecma standard proposed as an ISO standard.
- JTC 1 -- The ISO/IEC technical committee processing the EOOXML proposal.
- ODF -- OpenDocument Format, the existing ISO/IEC 26300:2006 standard.
This has now been 'cleaned up' to use ONLY 'ISO 26300' except in specific circumstances where an alternative use aids clarity. --Felix the Mac 20:30, 22 January 2007 (EST)
Add resource material links here, please. (Organized in alphabetical back-of-the-book subject indexing style, please.)
Links to blogs that cover technical aspects of EOOXML and/or ODF.
- Edwards, Gary OpenStack.
- Hiser, Sam PlexNex.
- Langhinrichs, Ben Genii Weblog (Self-deprecating standards article.)
- OpenDocument Fellowship Aggregator page, for blogs on the Fellowship site.
- OpenDocument Foundation fr0mat.net (has screengrabs of the da Vinci plug-in in use in Microsoft Word.)
- Open Malaysia Blog. covering the adoption of ODF as a National Standard in Malaysia and MSOOXML issues.
- Reuter, Florian Florian Reuter's Weblog.
- Sutor, Bob Striking the right chord, if you can find it., Ben
- Syndicated version of Sutor blog on IBM Developer site.
- Weir, Rob An Antic Disposition.
ISO/IEC Directives and complementary documents
JTC 1 / SC34
Ecma 376 has been submitted to JTC 1 and if accepted (after the 30 day review) will be assigned to sub-committee (SC) 34 for a 5-month ballot.
Note: This is the same sub-committee which approved OpenDocument Format (ODF) last year.
The details of SC34 can be found here:
JTC 1/SC34 Document description and processing languages
The JTC 1/SC34 website is http://www.jtc1sc34.org/.
Any of the P members of the full JTC 1 (listed here) may raise a Contradiction with the proposed standard during the 30 day review period. However, if no Contradiction is raised then the proposal is passed to this committee and any efforts to influence the outcome should be aimed at them.
Please do not flood this section with links that are not useful for the project. The purpose of this section is primarily to link key articles, mostly of a technical nature, that are candidates for being cited and/or quoted in the objections.
- Self-deprecating standards, by Ben Langhinrichs. (Examines vendor-specific tags in EOOXML.)
- How to hire Guillaume Portes, by Rob Weir, at An Antic Disposition.
- Is Open XML a one way specification for most people? by Bob Sutor. Analysis of EOOXML effects on competition because of vendor lock-in features.
- See also closely-related article, Interoperability vs. intraoperability: your open choice.
- Interoperability vs. intraoperability: your open choice, by Bob Sutor. Complements Sutor's earlier article, Is Open XML a one way specification for most people? Includes graphical depictions of concepts.
- OpenDocument Fellowship Precedent page (tracks ODF adoption by governments worldwide).
- Public sector deployments at OpenDocument.XML.org (tracks ODF adoption by governments worldwide).
ODF, application support
ODF, development tools
- Development tools at OpenDocument Fellowship.
- Programmatic support, filters, converters on Wikipedia.
- In one 49-MB PDF (official copy) Citations should be to this version's pagination.
- 5 January 2007
- EOOXML submitted to ISO for standardization.
- 5 February 2007
- Deadline for contradictions from ISO National Bodies
- Query, is the February 5 date confirmed? January has 31 days, so if submitted on 5 January, normal date calculations would make the deadline February 4.