New Zealand - SNZ

 

 

The DIS standard be considered by JTC 1 committee for publication as a Type 2 Technical report.

 

 

This DIS standard requires clarification – the lack of clarity may lead to ambiguity and inconsistent application.

 

 

 

Seek to harmonize with the existing ODF standard to reduce the:

  • cost of interoperability
  • cost of having two Standards
  • cost of support/maintenance
 

 

 

There needs to be clarification around the specification of non-required elements.

 

 

 

This DIS standard includes proprietary and undocumented behaviours/features.

 

 

 

Remove references to proprietary MS technology.

 

 

 

Māori, Multiculturalism

OOXML and ODF support Unicode (ISO/IEC 10646) in order to render all the letters and characters needed for Māori, many Polynesian, Asian, Aborigine languages, English, and many more.

So letters themselves are well dealt with but cultural expressiveness -- in the case of Office suites -- would of course allow cultural styles, calendar holidays for the Māori new year, etc.

OOXML contains mostly American and/or Christian symbols (Christmas Trees, Crosses, etc.) in a fixed and non-extensible list. This means that we can't add a border style of Matariki (Māori New Year stars), Koru Borders, Taniwhas, or other styles.

This fixed list is detailed in sections 2.18.4 (p. 2414, "Border Styles"), 5.1.12.56 (p. 4557, "Preset Shape Types"), and 5.1.12.76 (p. 4645, "Preset Text Shape Types").

 

The draft should allow either arbitrary images, or arbitrary images plus the existing fixed list, in order to allow multi-cultural styles.

 

 

    Human Readability of XML

There was a comparison of <cell> vs <c> in spreadsheets and which was faster. The goals of XML say, "6. XML documents should be human-legible and reasonably clear. 10.Terseness in XML mark-up is of minimal importance." -- http://www.w3.org/TR/REC-xml/#sec-origin-goals

This DIS contradicts the goals of XML and best practices.

The designers of XML knew what they were doing because while we can remember what "c" means in this case it becomes problematic when we get hundreds or thousands of these shorthand references. HTML, the web page language, has some shorthand references like this but then there are only around 20 things to memorize, so in practice it's not a problem. OOXML has hundreds of these cryptic names.

"Analogous wording shall be used to express analogous provisions; identical wording shall be used to express identical provisions.

Here's an example of identical wording referring to different things,

The w:sz element is an example of major internal inconsistencies in the specifications measurements:

  • For fonts, the w:sz element specifies the size in half points (2.3.2.36, page 1013).
  • For frameset, the w:sz element has a string value that could be a relative value, a percentage, or a number of pixels (2.15.2.39, page 2136). The examples on page 2138 do not refer to w:sz at all.
  • However, as the child of rPr (3.4.11, page 2846), its value is in points.
 

This DIS should be changed to follow the goals and best practices of XML by using human-legible terms and distinct terminology as required.

 

 

    Propagation of Historical Bugs

The bugs associated with the formulas and dates need to be resolved so that they remain compatible with them whilst not propagating their quirks to newly created documents.

Within OOXML there are ways of dealing with historical bugs (eg, autoSpaceLikeWord95). OpenFormula has an approach of adding additional flags to be compatible with historical bugs while preventing bug propagation in future documents. Eg,

There is a known bug that treats the year 1900 as a leap year. Changing the Gregorian calendar is not necessary (or the best way) to achieve compatibility with spreadsheets that depend on this bug. A better solution is to define the spec correctly, and when converting old binary files to the new format, Microsoft Office would (for example) replace WEEKDAY() by WEEKDAY()+1 for any dates affected by this bug. Alternatively, since they have compatibility flags for several other legacy bugs, this could be handled that way as well, e.g., when importing a legacy Excel document, set a flag "LeapYearBug=true", but when creating a new OOXML document this flag would not be set and dates would be described correctly.

The 1900 date problem needs to be addressed.

    There are also numerous mathematical bugs in SpreadSheetML such as CEILING, AVEDEV, ZTEST, CONFIDENCE, CONVERT, NETWORKDAYS, and at least another 30 more are affected. See http://urltea.com/zik?formulas and http://urltea.com/1blh?mathematically-incorrect
 

Repair all bugs and problems mentioned, further ones discovered, and remove any possibility for propagation of historical ones.

 

 

Intellectual Property

The term Intellectual Property is not a specific thing but an umbrella term for Copyright, Patents, Trademarks, etc.

It is crucial that a developer is able to access and use all or any information necessary to implement this DIS, without having to pay license fees, face patent issues, and not have information withheld, in accordance with the normal concepts of open source development over the life of the Standard

    1. Copyright

The clip art mentioned in sections 2.18.4, 5.1.12.56 and 5.1.12.76 should be checked for copyright issues.

    1. Patents

The Microsoft Open Specification Promise has this line about patent grant... which does grant "Microsoft-owned or Microsoft-controlled patents that are necessary to implement only the
required portions of the Covered Specification that are described in detail and not merely referenced in such Specification."

    The Covenant not to Sue has similar wording to do with a required subset of features, "Microsoft irrevocably covenants that it will not seek to enforce any of its patent claims necessary to conform to the technical specifications [...]".
 

All issues relating to IP, patents and access shall be examined in depth and irrevocable agreement obtained from Microsoft that all required access to information will be provided without monetary consideration, potential treat of legal action or issues relating to copyright. The provision of such information shall not be delayed or withheld.

 

 

    AccessibilityFile formats such as OOXML affect accessibility, and much accessibility software deals with files directly. An example of accessibility software dealing with files directly is "Blynx". A lot of accessibility benefits come from reusing existing tech (building upon existing standards which have accessibility software available).

Further, 'Docvert.org' software is currently used by disabled people to add structure to poorly made word processing files, which helps them navigate the pages (eg, because it can understand headings and such they can be read out summaries of the document without having to read the whole thing).

 

Improve and incorporate the impact on Accessibility considerations

 

 

    Proprietary Extensions and TechnologyThese are some undocumented Microsoft tech features present in OOXML, such as
    * SSPI ("Security Service Provider Interface") which is a proprietary Microsoft developed protocol for security providers.
    * OLE ("Object Linking and Embedding") which is for embedding (eg, taking an Excel spreadsheet and putting it into a Word document). This is undefined in OOXML only available on Microsoft Windows.On Windows many non-Microsoft Office Suites (such as OpenOffice, Word Perfect, etc.) have reverse engineered SSPI and OLE but the point is that in OOXML it's still undefined and it's still Windows-only tech that doesn't work on other platforms
 

OOXML needs to be clearly defined and expanded to work on all common platforms.

 

 

    Legacy data – binary data formats to be brought into the Standard.
 

The standard should include the binary data formats to ensure support for legacy data.

 

 

It is unsatisfactory to store printer settings in OS-dependent binary formats like DEVMODE structures. This is a considerable security concern (DEVMODE structures are loaded directly into device driver memory), as well as lacking cross-platform adaptability. There is also no interoperability with print settings as currently defined.

The DEVMODE structure stores many common settings, such paper orientation, paper size, number of copies, print quality, etc. There is no reason why these settings should be application or printer-specific. They should be stored in format that all applications can gain access to.

 

Printer settings should be stored in a format that is operating system independent, and in a format that promotes interoperability.

Alternatives are available for expressing print settings in XML rather than in binary. For example, Microsoft's own XPS specification defines a PrintTicket markup for which the XPS specifications says, “The PrintTicket is XML that provides print settings in a consistent, accessible, and extensible manner. We would like the same qualities in OOXML's print settings, not a binary blob.

 

 

OOXML lacks support for a feature of OpenOffice, namely blinking text.

 

Add support for blinking text.

 

 

OOXML lacks support for a feature of OpenOffice, namely Table cell protection.

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely an option to specify "Numbers of lines" for widow or orphans lines

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely 'Manual' and 'From left' alignment in tables

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Last line alignment in justified paragraph (provision that we can change the last line of the paragraph as Left, Center and Justify)

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely : allow 8192 table columns rather than OOXML's 63 limit

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: 'Leading' line spacing in a paragraph

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Tabs fill character of a paragraph

 

 

 

OOXML lacks support for a feature of OpenOffice, namely 'Title' and 'lowercase' style options

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: table can have 'keep with next paragraph' set

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: a 'May Break Between Rows' attribute so as not to split a table

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: allow entire sections to be marked as hidden

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Background Image in Tables -- background image can be defined for an entire table, a row or an individual cell. This image is automatically resized when modifying the table.

 

Include support for this feature

 

 

OOXML lacks support for a feature of OpenOffice, namely: Contents in a multi-column section can be evenly distributed resulting in balanced columns

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: an option to rotate the text by 90 as well as 270 degrees.

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: any number of rows can be selected for repeating Heading

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Copy Heading while splitting Table

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Table Shadowing Style

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: vertical numbering in list items

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: image can be positioned absolutely within a frame

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: ability to set arbitrary Text background colour

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Before/After text around foot notes references

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Keep ratio feature for frames

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Columns for frames/text-boxes

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: ability to assign different page colors throughout the document

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Notes embedded in text-boxes

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: ability to set each image border with different properties

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Background opacity

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: 'auto' option when application decide if a page break should be

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: font weights beyond just ‘normal’ and 'bold'.

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Table of content protection against manual changes

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: shadow distance, and a colour of shadow other than black

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Column separator attributes: width, colour, height, vertical-align.

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely : text-box can define the vertical alignment of text (top, centre, bottom)

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

This feature has been defined in a way which ignores the existence of current browsers other than Internet Explorer. This section requires that “all settings which are not compatible with the target web browser shall be disabled.”

 

Ecma should rethink the entire optimizeForBrowser subclause. It looks very much like it is mapping directly to the arbitrary choices of a single vendor's application. This clause should be rewritten to express this feature in an application and platform neutral way.

 

 

The specification does not disclose full interoperability information but relies in many instances on binary code that is not disclosed.

 

All necessary interoperability information needs to be disclosed. Further, all issues relating to IP, patents and access shall be examined in depth and irrevocable agreement obtained from Microsoft that all required access to information will be provided without monetary consideration, potential treat of legal action or issues relating to copyright..

 

 

The Specification contains the commands for every single feature that any Office version ever had, but does not tell the user which version.

 

Provide version information for the developer

 

 

The Specification continues to use binary code although a significant advantage of XML is that it is generally text based and therefore humanly readable. It contains extensive undocumented binary sections, referring to values instead of words, thereby removing the possibilities to understand the Specification without further explanation. This means that without a specific import/export filter, the content rendered will be unreadable.

 

Remove binary code and anything else which inhibits understanding of the Secification

Ensure content rendered is readable without need for a specific import/export filiter

 

 

Many of the binary sections refer back to Windows architecture which is unknown to software engineers outside Microsoft, and would require analytic and engineering work. Examples are found in font definition, conditional formatting for paragraph, table cell, table row, and table style settings.

 

Remove binary code and anything else which inhibits understanding of the Specification

 

 

Microsoft has given the 'Open Specification Promise', promising not to sue 3rd parties that use the Ecma specification for patent infringement. There are several issues outstanding with this:

(a) The Promise only relates to 'Microsoft Necessary Claims' which are "those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement only required portions of the Covered Specification that are described in detail and not merely referenced in such specification"

Firstly the boundaries of what is permitted and what is not are not clear.

Secondly, it is not determinable if the license is sufficient. If what Microsoft calls 'reference' equals the binary sections that refer back to Windows architecture, the promise does not give significant comfort given the large parts of binary XML sections in the Specification that are however needed to make a 3rd party solution interoperable with Microsoft's software.

Thirdly, the promise does not prevent Microsoft from obstructing third party implementations.

Fourthly, there are severe limitations for embedded formats. Microsoft is said to have a wide range of IP in all sorts of proprietary content which would be embedded in an OOXML doc, all of which would not be considered 'required' under the promise.

Finally it appears that the promise does not relate to copyrights but only to patents and leaves significant scope for legal uncertainty for 3rd party developers

 

All issues relating to IP, patents and access shall be examined in depth and irrevocable agreement obtained from Microsoft that all required access to information will be provided without monetary consideration, potential treat of legal action, issues relating to copyright, nor shall access to required information be denied or delayed.

 

 

 

The DIS standard be considered by JTC 1 committee for publication as a Type 2 Technical report.

 

 

This DIS standard requires clarification – the lack of clarity may lead to ambiguity and inconsistent application.

 

 

 

Seek to harmonize with the existing ODF standard to reduce the:

  • cost of interoperability
  • cost of having two Standards
  • cost of support/maintenance
 

 

 

There needs to be clarification around the specification of non-required elements.

 

 

 

This DIS standard includes proprietary and undocumented behaviours/features.

 

 

 

Remove references to proprietary MS technology.

 

 

 

    Māori, Multiculturalism

OOXML and ODF support Unicode (ISO/IEC 10646) in order to render all the letters and characters needed for Māori, many Polynesian, Asian, Aborigine languages, English, and many more.

So letters themselves are well dealt with but cultural expressiveness -- in the case of Office suites -- would of course allow cultural styles, calendar holidays for the Māori new year, etc.

OOXML contains mostly American and/or Christian symbols (Christmas Trees, Crosses, etc.) in a fixed and non-extensible list. This means that we can't add a border style of Matariki (Māori New Year stars), Koru Borders, Taniwhas, or other styles.

This fixed list is detailed in sections 2.18.4 (p. 2414, "Border Styles"), 5.1.12.56 (p. 4557, "Preset Shape Types"), and 5.1.12.76 (p. 4645, "Preset Text Shape Types").

 

The draft should allow either arbitrary images, or arbitrary images plus the existing fixed list, in order to allow multi-cultural styles.

 

 

    Human Readability of XML

There was a comparison of <cell> vs <c> in spreadsheets and which was faster. The goals of XML say, "6. XML documents should be human-legible and reasonably clear. 10.Terseness in XML mark-up is of minimal importance." -- http://www.w3.org/TR/REC-xml/#sec-origin-goals

This DIS contradicts the goals of XML and best practices.

The designers of XML knew what they were doing because while we can remember what "c" means in this case it becomes problematic when we get hundreds or thousands of these shorthand references. HTML, the web page language, has some shorthand references like this but then there are only around 20 things to memorize, so in practice it's not a problem. OOXML has hundreds of these cryptic names.

"Analogous wording shall be used to express analogous provisions; identical wording shall be used to express identical provisions.

Here's an example of identical wording referring to different things,

The w:sz element is an example of major internal inconsistencies in the specifications measurements:

  • For fonts, the w:sz element specifies the size in half points (2.3.2.36, page 1013).
  • For frameset, the w:sz element has a string value that could be a relative value, a percentage, or a number of pixels (2.15.2.39, page 2136). The examples on page 2138 do not refer to w:sz at all.
  • However, as the child of rPr (3.4.11, page 2846), its value is in points.
 

This DIS should be changed to follow the goals and best practices of XML by using human-legible terms and distinct terminology as required.

 

 

    Propagation of Historical Bugs

The bugs associated with the formulas and dates need to be resolved so that they remain compatible with them whilst not propagating their quirks to newly created documents.

Within OOXML there are ways of dealing with historical bugs (eg, autoSpaceLikeWord95). OpenFormula has an approach of adding additional flags to be compatible with historical bugs while preventing bug propagation in future documents. Eg,

There is a known bug that treats the year 1900 as a leap year. Changing the Gregorian calendar is not necessary (or the best way) to achieve compatibility with spreadsheets that depend on this bug. A better solution is to define the spec correctly, and when converting old binary files to the new format, Microsoft Office would (for example) replace WEEKDAY() by WEEKDAY()+1 for any dates affected by this bug. Alternatively, since they have compatibility flags for several other legacy bugs, this could be handled that way as well, e.g., when importing a legacy Excel document, set a flag "LeapYearBug=true", but when creating a new OOXML document this flag would not be set and dates would be described correctly.

The 1900 date problem needs to be addressed.

    There are also numerous mathematical bugs in SpreadSheetML such as CEILING, AVEDEV, ZTEST, CONFIDENCE, CONVERT, NETWORKDAYS, and at least another 30 more are affected. See http://urltea.com/zik?formulas and http://urltea.com/1blh?mathematically-incorrect
 

Repair all bugs and problems mentioned, further ones discovered, and remove any possibility for propagation of historical ones.

 

 

Intellectual Property

The term Intellectual Property is not a specific thing but an umbrella term for Copyright, Patents, Trademarks, etc.

It is crucial that a developer is able to access and use all or any information necessary to implement this DIS, without having to pay license fees, face patent issues, and not have information withheld, in accordance with the normal concepts of open source development over the life of the Standard

    1. Copyright

The clip art mentioned in sections 2.18.4, 5.1.12.56 and 5.1.12.76 should be checked for copyright issues.

    1. Patents

The Microsoft Open Specification Promise has this line about patent grant... which does grant "Microsoft-owned or Microsoft-controlled patents that are necessary to implement only the
required portions of the Covered Specification that are described in detail and not merely referenced in such Specification."

    The Covenant not to Sue has similar wording to do with a required subset of features, "Microsoft irrevocably covenants that it will not seek to enforce any of its patent claims necessary to conform to the technical specifications [...]".
 

All issues relating to IP, patents and access shall be examined in depth and irrevocable agreement obtained from Microsoft that all required access to information will be provided without monetary consideration, potential treat of legal action or issues relating to copyright. The provision of such information shall not be delayed or withheld.

 

 

    AccessibilityFile formats such as OOXML affect accessibility, and much accessibility software deals with files directly. An example of accessibility software dealing with files directly is "Blynx". A lot of accessibility benefits come from reusing existing tech (building upon existing standards which have accessibility software available).

Further, 'Docvert.org' software is currently used by disabled people to add structure to poorly made word processing files, which helps them navigate the pages (eg, because it can understand headings and such they can be read out summaries of the document without having to read the whole thing).

 

Improve and incorporate the impact on Accessibility considerations

 

 

    Proprietary Extensions and TechnologyThese are some undocumented Microsoft tech features present in OOXML, such as
    * SSPI ("Security Service Provider Interface") which is a proprietary Microsoft developed protocol for security providers.
    * OLE ("Object Linking and Embedding") which is for embedding (eg, taking an Excel spreadsheet and putting it into a Word document). This is undefined in OOXML only available on Microsoft Windows.On Windows many non-Microsoft Office Suites (such as OpenOffice, Word Perfect, etc.) have reverse engineered SSPI and OLE but the point is that in OOXML it's still undefined and it's still Windows-only tech that doesn't work on other platforms
 

OOXML needs to be clearly defined and expanded to work on all common platforms.

 

 

    Legacy data – binary data formats to be brought into the Standard.
 

The standard should include the binary data formats to ensure support for legacy data.

 

 

It is unsatisfactory to store printer settings in OS-dependent binary formats like DEVMODE structures. This is a considerable security concern (DEVMODE structures are loaded directly into device driver memory), as well as lacking cross-platform adaptability. There is also no interoperability with print settings as currently defined.

The DEVMODE structure stores many common settings, such paper orientation, paper size, number of copies, print quality, etc. There is no reason why these settings should be application or printer-specific. They should be stored in format that all applications can gain access to.

 

Printer settings should be stored in a format that is operating system independent, and in a format that promotes interoperability.

Alternatives are available for expressing print settings in XML rather than in binary. For example, Microsoft's own XPS specification defines a PrintTicket markup for which the XPS specifications says, “The PrintTicket is XML that provides print settings in a consistent, accessible, and extensible manner. We would like the same qualities in OOXML's print settings, not a binary blob.

 

 

OOXML lacks support for a feature of OpenOffice, namely blinking text.

 

Add support for blinking text.

 

 

OOXML lacks support for a feature of OpenOffice, namely Table cell protection.

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely an option to specify "Numbers of lines" for widow or orphans lines

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely 'Manual' and 'From left' alignment in tables

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Last line alignment in justified paragraph (provision that we can change the last line of the paragraph as Left, Center and Justify)

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely : allow 8192 table columns rather than OOXML's 63 limit

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: 'Leading' line spacing in a paragraph

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Tabs fill character of a paragraph

 

 

 

OOXML lacks support for a feature of OpenOffice, namely 'Title' and 'lowercase' style options

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: table can have 'keep with next paragraph' set

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: a 'May Break Between Rows' attribute so as not to split a table

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: allow entire sections to be marked as hidden

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Background Image in Tables -- background image can be defined for an entire table, a row or an individual cell. This image is automatically resized when modifying the table.

 

Include support for this feature

 

 

OOXML lacks support for a feature of OpenOffice, namely: Contents in a multi-column section can be evenly distributed resulting in balanced columns

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: an option to rotate the text by 90 as well as 270 degrees.

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: any number of rows can be selected for repeating Heading

 

Include this feature in WordProcessingML in order to improve interoperability.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Copy Heading while splitting Table

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Table Shadowing Style

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: vertical numbering in list items

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: image can be positioned absolutely within a frame

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: ability to set arbitrary Text background colour

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Before/After text around foot notes references

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Keep ratio feature for frames

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Columns for frames/text-boxes

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: ability to assign different page colors throughout the document

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Notes embedded in text-boxes

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: ability to set each image border with different properties

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Background opacity

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: 'auto' option when application decide if a page break should be

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: font weights beyond just ‘normal’ and 'bold'.

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Table of content protection against manual changes

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: shadow distance, and a colour of shadow other than black

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely: Column separator attributes: width, colour, height, vertical-align.

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

OOXML lacks support for a feature of OpenOffice, namely : text-box can define the vertical alignment of text (top, centre, bottom)

 

Include support for this feature from ISO ODF in order to improve interoperability between the two formats.

 

 

This feature has been defined in a way which ignores the existence of current browsers other than Internet Explorer. This section requires that “all settings which are not compatible with the target web browser shall be disabled.”

 

Ecma should rethink the entire optimizeForBrowser subclause. It looks very much like it is mapping directly to the arbitrary choices of a single vendor's application. This clause should be rewritten to express this feature in an application and platform neutral way.

 

 

The specification does not disclose full interoperability information but relies in many instances on binary code that is not disclosed.

 

All necessary interoperability information needs to be disclosed. Further, all issues relating to IP, patents and access shall be examined in depth and irrevocable agreement obtained from Microsoft that all required access to information will be provided without monetary consideration, potential treat of legal action or issues relating to copyright..

 

 

The Specification contains the commands for every single feature that any Office version ever had, but does not tell the user which version.

 

Provide version information for the developer

 

 

The Specification continues to use binary code although a significant advantage of XML is that it is generally text based and therefore humanly readable. It contains extensive undocumented binary sections, referring to values instead of words, thereby removing the possibilities to understand the Specification without further explanation. This means that without a specific import/export filter, the content rendered will be unreadable.

 

Remove binary code and anything else which inhibits understanding of the Secification

Ensure content rendered is readable without need for a specific import/export filiter

 

 

Many of the binary sections refer back to Windows architecture which is unknown to software engineers outside Microsoft, and would require analytic and engineering work. Examples are found in font definition, conditional formatting for paragraph, table cell, table row, and table style settings.

 

Remove binary code and anything else which inhibits understanding of the Specification

 

 

Microsoft has given the 'Open Specification Promise', promising not to sue 3rd parties that use the Ecma specification for patent infringement. There are several issues outstanding with this:

(a) The Promise only relates to 'Microsoft Necessary Claims' which are "those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement only required portions of the Covered Specification that are described in detail and not merely referenced in such specification"

Firstly the boundaries of what is permitted and what is not are not clear.

Secondly, it is not determinable if the license is sufficient. If what Microsoft calls 'reference' equals the binary sections that refer back to Windows architecture, the promise does not give significant comfort given the large parts of binary XML sections in the Specification that are however needed to make a 3rd party solution interoperable with Microsoft's software.

Thirdly, the promise does not prevent Microsoft from obstructing third party implementations.

Fourthly, there are severe limitations for embedded formats. Microsoft is said to have a wide range of IP in all sorts of proprietary content which would be embedded in an OOXML doc, all of which would not be considered 'required' under the promise.

Finally it appears that the promise does not relate to copyrights but only to patents and leaves significant scope for legal uncertainty for 3rd party developers

 

All issues relating to IP, patents and access shall be examined in depth and irrevocable agreement obtained from Microsoft that all required access to information will be provided without monetary consideration, potential treat of legal action, issues relating to copyright, nor shall access to required information be denied or delayed.