Abonner
KOMMENTARER

- Ni kommentarer ble ikke tatt hensyn til

NUUG mener OOXML er en ufullstendig spesifikasjon, og at den derfor ikke bør brukes.

Del
Kommenter
Anders Brenna
7. apr. 2008 - 14:48

Etter en lang og opphetet diskusjon er Microsoft's dokumentformat OOXML godkjent som ISO-standard.

    Les også:

Artikkelen fortsetter etter annonsen
annonsørinnhold
Atea
Ikke kast bort tiden på dårlige løsninger for videomøter

Stridens fokus vil nå flyttes over på om Norges regjering ved Fornyingsminister Heidi Grande Røys bør gjøre. Hun må avgjøre om OOXML skal føres opp på listen over godkjente formater som offentlige etater kan publisere i. På den listen står foreløpig bare HTML, PDF og ODF.

Norwegian Unix Users Group (NNUG) mener OOXML er et uegnet format, og leder i Petter Reiholdtsen har skrevet en lengre forklaring av hvorfor de mener det.

Her følger innlegget fra NUUG i sin helhet, samt med vedlegg der alle de norske bemerkningene er kommentert:

ECMA OOXML - en ufullstendig spesifikasjon som få kan implementere

Debatten rundt ISO-standardisering av OOXML pågår fortsatt, og endel undrer kanskje på hvorfor det er viktig. NUUG er involvert i standardisering for å fremme samvirke og like konkurransevilkår for alle aktører, og når det gjelder dokumentstandarder, sikre at dagens og gårsdagens dokumenter også kan leses korrekt i framtiden, det være seg om 10 eller 200 år.

OOXML er en dårlig spesifikasjon som ikke fremmer samvirke og antagelig heller ikke kan implementers av andre enn de som har tilgangen til interne algoritmer i MS Office OOXML er en dårlig spesifikasjon som ikke fremmer samvirke og antagelig heller ikke kan implementers av andre enn de som har tilgangen til interne algoritmer i MS Office. Den bør derfor ikke tas i bruk som lagringsformat for framtidens dokumenter. ISO-godkjenning endrer dessverre ikke på dette, og problemene kan tidligst være fikset om 4 år dersom ISO skal gjøre dette. Da forutsettes at ISO og ECMA øyeblikkelig blir enige om at ISO skal vedlikeholde spesifikasjonen, og at ISO like øyeblikkelig starter prosessen for å korrigere den. En god del av feilene kan dessuten bare fikses hvis en får tilgang til informasjon som i dag bare er tilgjengelig for de som har tilgang til intern oppførsel i MS Office. Vi har så langt ingen indikasjoner på at MS kommer til å gjøre disse offentlig tilgjengelige.

I den norske debatten rundt OOXML har det blitt hevdet at de 12 kommentarene som var knyttet til Norges nei-stemme, i det store og hele var tatt hensyn til da stemmen ble endret til ja. Dette stemmer ikke, og er en viktig grunn til at så få i den norske komiteen støttet Microsofts ønske om å endre den norske stemmen. I tillegg til at 80% av dagens komitemedlemmer var imot å godkjenne OOXML som ISO-standard, er det verdt å nevne at 100% av de originale medlemmene i komiteen, dvs som var medlemmer før OOXML kom opp,ville stemme nei.

Realiteten er dermed ikke slik Standard Norge og Microsofts innleide lobbyist Shahzad Rana har hevdet, da kun et fåtall av kommentarene var tatt hensyn til, og de aller fleste ble ignorert og påstått tatt hensyn til ved at det ble gjort irrelevante endringer.

Ni kommentarer ble ikke tatt hensyn til (1, 2, 3, 4, 6, 8, 9, 11, 12), to ble delvis tatt hensyn til (7, 10), og en ble tatt fullstendig hensyn til (5).

Vedlegg: How were Norway's OOXML comments handled?

In the first vote on the proposed OOXML standard in 2007, Norway voted No and submitted twelve technical comments that would have to be addressed before the Norwegian vote would change to Yes. This document lists the Norwegian comments and the resulting outcomes. In summary, nine of the twelve comment were not addressed (1, 2, 3, 4, 6, 8, 9, 11, 12), two were partially addressed (7, 10), and one was fully addressed (5).

The Norwegian comments are available as PDF from Standard Norge.

NO-01 The Scope clause in Part 1 is inappropriate for an ISO standard

Justification:

* The Scope clause is self-referential, does not convey any useful

information, and does not conform to JTC1 and ISO Directives for

the scope of a standard or NP (ref. JTC1 Directives, 6.2.1.6; ISO

Directives, Part 2, 6.2.1 Scope). In the absence of an appropriate

Scope clause it is not possible to resolve a number of issues

arising from the current text.

Proposed change by the MB:

* The Scope clause should be rewritten to give a succinct overview

of the contents of the standard without self-reference, for

example: "This International Standard specifies a set of XML

vocabularies for representing legacy documents produced by MS

Office applications. It covers word processing, spreadsheet,

presentation and graphics documents produced by the following

versions of MS Office applications: [list supported versions] It

does not cover documents produced by other office applications."

The exact form of the Scope clause will depend on what decisions

are taken regarding the final structure of the standard (e.g. as a

multi-part standard).

Change accepted in OOXML:

* Scope clause was changed and restructured. All parts of 29500

shall have the following clause:

+ "# Scope clause

This International Standard defines a set of XML vocabularies for

representing word-processing documents, spreadsheets and presentations.

The goal of this standard is, on the one hand, to represent faithfully

the existing corpus of word-processing documents, spreadsheets and

presentations that have been produced by Microsoft Office applications

(from Microsoft Office 97 to Microsoft Office 2008 inclusive). It also

specifies requirements for Office Open XML consumers and producers ,

and on the other hand, to facilitate extensibility and interoperability

by enabling implementations by multiple vendors and on multiple

platforms.

This part specifies concepts for documents and applications of strict

and transitional conformance."

In addition each part will have a sub clause specifying the exact scope for

that part. In addition each scope clause shall have a reference to the

informative specification of the following:

+ All XML elements which appear in ISO/IEC 29500 but do not appear in

ECMA-376:2006

+ All XML elements which do not appear in ISO/IEC 29500 but appear in

ECMA-376:2006

+ All XML attributes which appear in ISO/IEC 29500 but do not appear in

ECMA-376:2006

+ All XML attributes which do not appear in ISO/IEC 29500 but appear in

ECMA-376:2006

+ All enumeration values which appear in ISO/IEC 29500 but do not appear

in ECMA-376:2006

+ All enumeration values which do not appear in ISO/IEC 29500 but appear

in ECMA-376:2006

+ All simple types which appear in ISO/IEC 29500 but do not appear in

ECMA-376:2006

+ All simple types which do not appear in ISO/IEC 29500 but appear in

ECMA-376:2006

Conclusion:

* The word "legacy" was not added to the document, neither has the

statement about "other office applications". It is also

interesting to note that "existing corpus of word- processing

documents, spreadsheets and presentations" does not include

Microsoft office applications before Office 97. Part of the

reasoning for this comment was to learn if the specification only

should be used for legacy documents, and thus not compete with ODF

on representing future documents, or if it also was to represent

future documents. If it is to represent future documents, it

should be rejected as it competes with ODF. The BRM did not want

to limit the scope of the standard to representing legacy

documents, and wanted it to be used for new documents as well. The

Norwegian comment has therefore not been addressed.

NO-02 Rework into a multi-part standard.

Justification:

* As currently drafted, DIS 29500 covers many areas that are not

directly related to one another. This makes it difficult to review

by National Body experts, difficult to implement, and difficult to

assess compatibility.

Proposed change by the MB:

* Rework into an ISO-style multi-part standard along the following lines:

1. Introduction

2. Common/Core components and metadata

3. WordprocessingML

4. SpreadsheetML

5. PresentationML

6. Extensibility

Each part should have its own Scope and Conformance clause. This

would allow different parts of the standard to be used

independently of each other. The Primer is informative and should

be published as a Technical Report.

Change accepted in OOXML:

* The specification will be reorganised, but not along the lines of

functionally similar sections.

+ The proposed parts are now 1) Fundamentals and Markup Language

Reference, 2) Open Packaging Convention, 3) Markup

Compatibility and Extensibility and 4) Transitional Features.

Conclusion:

* The specification was not changed in a way that allows different

parts to be used independently, and thus Norway's proposal was not

implemented. The Norwegian comment has therefore not been

addressed.

NO-03 Rework into a much more concise standard.

Justification:

* The text of DIS 29500 is too voluminous to be reliably reviewed by

National Body experts, or for implementations to be assessed for

compatibility. It appears to be unnecessarily long, combining

normative text with copious examples and containing a lot of

redundancy.

Proposed change by the MB:

* The text should be shortened considerably, through the removal of

non-normative text (into annexes), the avoidance of redundancy and

other means.

Change accepted in OOXML:

* As far as we know, no relevant change was done. Instead, adding

1400 pages of "collected XML syntax" was accepted as a change.

Conclusion:

* Since the new version of the standard is not available it is

impossible to know whether the specification will be longer or

shorter. Most likely our request on a more concise standard will

not be met. Since much information on deprecated features is to be

moved to "Transitional parts of the document", the standard will

become harder to read since you need to check several places in

the documentation to understand how to use the standard. The

Norwegian comment has therefore not been addressed.

NO-04 The information model is unnecessarily complex.

Justification:

* The XML information model described is unnecessarily

complex. Given the example in the Overview at page 13 (§5.6)

Hello, world.

* Could - and should - be represented as:

Hello, world.

Proposed change by the MB:

* Simplify the information model and document structure, in order to

ease implementation, interoperability and the processing of the

OOXML documents. Where possible use notations in conformance with

ODF.

Change accepted in OOXML:

* This change was rejected.

Conclusion:

* OOXML did not change according to the proposal from Norway. This

comment has therefore not been addressed.

NO-05 All examples should conform to the XML specification

Justification:

* More than 10% of the examples are not valid XML. This will cause

confusion and could lead to differences in implementation that

will inhibit interoperability.

Proposed change by the MB:

* All examples should be valid XML, except where there is an express

intent to exemplify invalid data.

Change accepted in OOXML:

* This change was accepted.

Conclusion:

* OOXML was promised to change according to the proposal from

Norway. The Norwegian comment has therefore been addressed.

NO-06 DrawingML should be a separate standard

Justification:

* DrawingML has general applicability as an XML vocabulary for

vector graphics. It should therefore be a standard in its own

right that can be referenced in isolation by other ISO standards,

such as ISO 26300.

Proposed change by the MB:

* Remove DrawingML from 29500 and propose it as a separate standard,

or commit to doing so at a later stage.

Change accepted in OOXML:

* It is proposed that the following editorial change be made to the DrawingML

specification:

1. The DrawingML specification is to be reorganized into two sections

1. DrawingML - Framework

2. DrawingML - Components

2. The following sections in the DrawingML specification will be moved

into the "DrawingML - Components" section

1. DrawingML - Paragraphs and Rich Formatting, Section 5.1.5

2. DrawingML - Tables, Section 5.1.6

3. DrawingML - Charts, Section 5.7

4. DrawingML - Chart Shapes, Section 5.8

5. DrawingML - Diagrams, Section 5.9

3. All remaining sections of the DrawingML specification will be moved

into the "DrawingML - Framework" section.

Conclusion:

* The sections on DrawingML were collected into a separate chapter,

and some statements were made that this could be separated out at

a later stage, but no commitment could be made about the work of a

future group. DrawingML was not proposed as a separate standard,

and there was no commitment for doing so at a later stage. The

Norwegian comment has therefore not been addressed.

NO-07 OPC should be a separate standard

Justification:

* The Open Packaging Conventions could support a much broader range

of applications than OOXML. It should therefore be a standard in

its own right that can be referenced in isolation by other ISO

standards, such as ISO 26300.

Proposed change by the MB:

* Remove OPC from 29500 and propose it as a separate standard, or

commit to doing so at a later stage.

Change accepted in OOXML:

* OPC is now a separate part of the standard, but not a separate

standard. The claim was made that processing of a PAS, once

entered, cannot result in creation of multiple standards.

Conclusion:

* The Norwegian proposal was to submit OPC as a separate standard

proposal, not to use this PAS process to create multiple

standards. Reusing OPC when it is a chapter in 29500 with possible

references to the rest of 29500 will be harder than if it was a

separate standard. The Norwegian comment has therefore been

partially addressed.

NO-08 The specification should not include binary notations

Justification:

* Unspecified (or underspecified) binary notations, especially those

with operating system dependencies, inhibit interoperability and

do not belong in an ISO standard. Even well-specified binary

notations, such as bitmasks used to encode multiple boolean

values, are inappropriate in an XML-based interchange

format. Non-standard text-based encodings of control characters,

such as 'bstr' (basic string) are also inappropriate.

Proposed change by the MB:

* All references to platform specific and/or binary notations, such

as DEVMODE for printer settings and bitmasks for boolean values,

should be removed and, where possible, replaced by open, XML-based

standards, more explicit XML vocabulary, or base64 encoding.

Change accepted in OOXML:

* Some of the constructs pointed at were better documented.

* Some of the constructs were marked "transitional".

* The ability to include objects in undocumented binary formats was kept.

* DEVMODE was kept, and was not marked "transitional".

Conclusion:

* The Norwegian comment has not been addressed.

NO-09 The specification should not contain underspecified features

Justification:

* Underspecified features and settings, such as "autoSpaceLikeWord95",

"footnoteLayoutLikeWW8", "lineWrapLikeWord6", "mwSmallCaps",

"optimizeForBrowser", "shapeLayoutLikeWW8", "supressTopSpacingWP",

"truncateFontHeightsLikeWP6", "useWord2002TableStyleRules",

"useWord97LineBreakRules", "useWord97LineBreakRules", "wpJustification",

"wpSpaceWidth", "sldSyncPr", "securityDescriptor", and "revisionsPassword"

preclude uniform implementation and thus inhibit interoperability.

Proposed change by the MB:

* All features should be specified in enough detail to enable

uniform interpretation by multiple implementations. Those that

cannot be specified in sufficient detail should be removed.

Change accepted in OOXML:

* Some (or all, have not checked all) of the underspecified features

got more documentation, but the specifications checked so far was

vague and not detailed enough for a developer to use it to get the

same result without reverse engineering MS Word.

Conclusion:

* As the whole point of this comment was to ensure uniform

interpretation by multiple implementations to make sure the OOXML

documents are processed and displayed the same way in all

implementations of OOXML, it is clear that OOXML was not changed

according to this comment. We did not ask for more text, we asked

for specification in enough detail to enable uniform

interpretation by multiple implementations, and removal of all

features lacking this. The Norwegian comment has therefore not

been addressed.

NO-10 Option sets should be extensible and should avoid cultural bias

Justification:

* Options to features such as border styles, enumeration styles,

list styles, the function NETWORKDAYS(), Clipboard Format Type,

etc. should not exhibit cultural bias or be unduly restrictive,

since this will inhibit adoption internationally.

Proposed change by the MB:

* All such features should be made extensible wherever possible and

defined options should be specified in full in order to enable

uniform implementation.

Change accepted in OOXML:

* New features were added that could do the functions pointed at in

culturally acceptable ways.

* The current features were marked "transitional".

Conclusion:

* The committee attempted to address the issue, but the result was a more

complex standard. The Norwegian comment has therefore been partially

addressed.

NO-11 OOXML should reference, use, and conform to existing standards where applicable

Justification:

* It has been claimed that the current standard conflicts with other

ISO standards, such as ISO 8601 (Representation of dates and

times), ISO 639 (Codes for the representation of names of

languages) and ISO/IEC 10118-3 (Hash functions). If this is the

case, the specification should be brought into line with these and

other existing standards. The problem is especially apparent in

the case of the 'date1904' attribute. The ambiguity regarding the

status of the year 1900 should be resolved by using ISO standard

dates everywhere.

Proposed change by the MB:

* Ensure that 29500 does not conflict with the above-mentioned

standards and use only ISO standard date formats, not ambiguous

numeric dates.

Change accepted in OOXML:

* The existing parts of the specification using a different date

specification, language names and hash functions were kept. The

use of ISO 8601 dates were added, thus forcing those implementing

this specification to implement at least three different date

formats, and some of them are not following the Gregorian calendar

system. Similar was done for ISO 639, where both the original

language definition was kept while it is also possible to use

language codes from ISO 639, forcing implementations to handle two

separate sets of language codes.

Conclusion:

* OOXML did not change according to the proposal from Norway. The Norwegian

comment has therefore not been addressed.

NO-12 Lack of consistency in notation of values and dimensions

Justification:

* There is no coherent dimension notation throughout the

specification, for instance the relative dimension "87,5%" is

sometimes represented by "pct87", sometimes by "87500" or even by

"4375". This will cause confusion and could lead to

non-interoperable implementations.

Proposed change by the MB:

* Put in place a coherent value system.

Change accepted in OOXML:

* On percentages, the fields were changed to accept two different

formats, the old format and a format that was a text string

followed by a "%" (percent sign) character.

Conclusion:

* The specification still does not have a coherent value

system. Length units, colour settings, etc are still represented

using several different notations. This makes it hard to implement

the specification and will lead to confusion and interoperability

problems. Adding more type of values (as an extra notation for

percent values) only increases the problem. OOXML did not change

sufficiently according to the proposal from Norway. The Norwegian

comment has therefore not been addressed.

    Les også:

Les mer om:
KOMMENTARER
Del
Kommentarer:
Du kan kommentere under fullt navn eller med kallenavn. Bruk BankID for automatisk oppretting av brukerkonto.
Tekjobb
Se flere jobber
Forbrukerrådet
Azure utviklere
Forbrukerrådet
Oslo
19. mai
    En tjeneste fra