Template for comments and secretariat observations


Part 4, Section 1.2 SpreadsheetML Part Summary



Download 299.49 Kb.
Page2/4
Date conversion09.07.2018
Size299.49 Kb.
1   2   3   4
Part 4, Section 1.2 SpreadsheetML Part Summary


page 1, line 6

ed

Table row 'Custom Property' is deemed to have no root element and no reference. The value of this row is unclear.

Clarify the table purpose.




PT

Part 4, Section 1.5 Shared Part Summary

page 3, line 1

ed

Eleven table rows are deemed to have no root element and no reference. The value of these rows is unclear.

Clarify the table purpose.




PT

Part 4, Section 2.15.1.28

-

te

This says that document protection “shall be enforced”. “Shall” indicates required behavior. But then a few sentences later it says that document protection “may be ignored”.

Clarify this contradiction.




PT

Part 4, Section 2.15.1.28

line 13

te

This algorithm description fails to specify the encoding of the input password. Presumably it is Unicode, but in what encoding? UTF-16BE? UTF-16LE? UTF-16 with a BOM (Byte Ordering Mark)? The described algorithms make use of byte-level manipulations which depend on the machine architecture (big endian versus little endian). So it is necessary that all byte ordering assumptions be made explicit.


Make the byte ordering assumptions explicit, both for the input password and the processing steps, so as to allow cross-platform interoperability. Keep in mind that the hash may be calculated on a different machine architecture than the password was entered with.




PT

Part 4, Section 2.15.1.28

line 16

te

What if the entered password is shorter than 15 characters? Do we truncate to the actual length? Or fill with 0's? Or something else?

Clarify this processing step.




PT

Part 4, Section 2.15.1.28

pg 1159, lines 6-9

te

The described processing steps are not ambiguous. In particular SHR and SHL give different results on different machines and with signed and unsigned values

Describe the hash algorithm in a platform independent manner.




PT

Part 4, Section 2.15.1.29

-

te


This element allows the classification of the document into one of three types: “letter”, “email” or “general”. Although the description says that this feature can be used by, “hosting applications to facilitate customized user interface and/or automatic formatting behaviors based on the 'type' of a given WordprocessingML document”, the taxonomy provided is so weak as to be practically useless.

Either provide a reasonable document type taxonomy, or loosen the type to an xsd:string to allow applications to provide their own.




PT

Part 4

Section 2.15.3.6 and others






te

The emulation (backward compatibility) functions for legacy systems must not be mixed with the specification's functions that reflect the technological state-of-the-art, as per Part 4.

Such a separation will make it easier to understand and implement a current specification considering the methods specified in ECMA 376, without having to worry about the backward compatibility methods that currently appear in the middle of all the other sub-specifications.

Such a separation will also help mitigating the complexity the task of using a current implementation and getting a clearer idea of the methods that have to be implemented to assure backward compatibility in that implementation.

The emulation functions described in the specification (in example 2.15.3.6 – autoSpaceLikeWord95 and others) should be specified individually and put in a new separate part of the standard (e.g., Part 6 – Emulation Methods to Provide For Backward Compatibility), so as to isolate the updated specification from the backward compatibility specification.

This would make the current specification easy, clear and easy to implement for implementers that do not want to have to think about legacy systems. On the other hand, the main specification would become technically 'purer' as the complexity of implementing the emulation methods would be eliminated altogether.

The emulation methods could therefore basically work like an extension to the main specification that an implementer might or not want to use as the extension is part of the global OpenXML specification.





PT

Part 4

Section 2.15.3.6 and others






te

No technical specification is provided for the implementation of any of the backward compatibility functions mentioned in the previous item and in the ECMA specification 376. All that is provided is basic Guidance.

In example 2.15.3.6, the specification differs from item 2.15.3.5 and is also less detailed.



In addition the guidelines mentioned, the backward compatibility items should also include a corresponding technical description which – even if short – could be used as implementation guidance, so that the implementer won't have to read or study the mentioned external sources in order to reproduce behaviors (e.g., Word 95). More details are provided in the next 11 comments.

In proposed new Part 6 mentioned above, (Part 6 – Emulation Methods to Provide For Backward Compatibility), include for instance the required technical expansion for each item to provide the implementer with the information required to reproduce the original behavior.




PT

Part 4, Section 2.15.3.26

-

te

This is the “footnoteLayoutLikeWW8” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior.


Define the intended behavior.




PT

Part 4, Section 2.15.3.31

-

te

This is the “lineWrapLikeWord6” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.




PT

Part 4, Section 2.15.3.32

-

te

This is the “mwSmallCaps” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.




PT

Part 4, Section 2.15.3.41

-

te

This is the “shapeLayoutLikeWW8” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.





PT

Part 4, Section 2.15.3.51

-

te

This is the “suppressTopSpacingWP” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.




PT

Part 4, Section 2.15.3.54

-

te

This is the “ uiCompat97To2003” element, which is defined as: “Disable UI functionality that is not compatible with Word97-2003”. But what use is this if I am using OOXML in OpenOffice or WordPerfect Office? What if I want to disable UI functionality that is not compatible with OpenOffice 1.5? Or WordPerfect 8? Or any other application? Where is the ability for other implementations to specify their preferences?

Define this in an application neutral way. If it is truly a Word-only feature, then remove it from OOXML and express as an application-defined extension.




PT

Part 4, Section 2.15.3.54

-

te


This is the “truncateFontHeightsLikeWP6” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.




PT

Part 4, Section 2.15.3.6

-

te

This is the “autoSpaceLikeWord95” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.




PT

Part 4, Section 2.15.3.63

-

te

This is the “useWord2002TableStyleRules” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.




PT

Part 4, Section 2.15.3.64

-

te


This is the “useWord97LineBreakRules” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.




PT

Part 4, Section 2.15.3.65

-

te

This is the “ wpJustification” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.




PT

Part 4, Section 2.15.3.66

-

te

This is the “wpSpaceWidth” element, which is defined in terms of mimicking a legacy application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.




PT

Part 4, Section 2.16.4.3

page 1501, line 0

te

The definition for BATHTEXT references 'the given Thai format', which makes no sense in the context of that definition. What “given Thai format”?


Clarify the definition of 'BATHTEXT'.




PT

Part 4, Section 2.16.5.33

-

te

This field says that it merely retrieves the picture contained in the named document. Is there nothing else to be done with the picture? For example, should it be displayed?

Define what is to be done with the picture once it is retrieved.




PT

Part 4, Section 2.16.5.33

-

te

This does not define how a picture is named. Is it by a URI? By a local file system path? Either? The example given has a DOS file path, a construct which is not portable.

Define how pictures are named.




PT

Part 4, Section 2.16.5.33

-

te

This subclause defines an INCLUDEPICTURE field which “Retrieves the picture contained in the document named”. However, no mention is made of what formats are permissible for the picture.


There should be specified at least a small set of interoperable formats.




PT

Part 4, Section 2.16.5.34

-

te

This subclause defines an INCLUDETEXT field which “Inserts all or part of the text and graphics contained in the document named”. However, no mention is made of what formats are permissible for the retrieved text.

There should be specified at least a small set of interoperable formats.




PT

Part 4, Section 2.16.5.34

-

te

The \t flag will apply a named XSLT transform to the input XML file and insert the resulting output. However, no proper reference is given to XSLT, so we do not know what version XSLT transform is permitted here.

Provide a proper external normative reference for the XSLT which is allowed here.




PT

Part 4, Section 2.16.5.40

page 1543, line 12&13

te

The definition for 'LISTNUM' is built upon the concepts of 'current' or 'specific' or 'next series', which are not defined in this context (a backward search on 'series' shades no light on this). Those concepts should be defined in the text, and their definition should either be copied or referenced in the context of the definition for 'LISTNUM'.


Expand or reference the definition for 'series', and/or clarify the definition for 'LISTNUM' by any appropriate means.




PT

Part 4, Section 2.16.5.77

-

te

The example that illustrates USERINITIALS section shows instead USERNAME.

Correct the example.




PT

Part 4, Section 2.18.106

-

te

Length is said to be “exactly 1 character”. This is inconsistent with the earlier language and the schema fragment given which defines it as being 1 octet long or two characters.

Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.




PT

Part 4, Section 2.18.4

-

te

The artwork provided here is of poor quality providing neither intended scale, spacing, color depth, etc. A small example diagram is an insufficient definition. For example, are the dimensions of the borders absolute? Or do they scale with page size? Also, some of the images, such as 'apples' or 'balloons3Colors' show copying artifacts, where extraneous lines or blotches appear.


Provide full normative definitions for these graphical elements. Also, for informative purposes, these graphics may be provided in standalone file form.




PT

Part 4, Section 2.18.45

-

te

Length is said to be “exactly 3 characters”. This is inconsistent with the example given which has a length of 6 characters.

Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.




PT

Part 4, Section 2.18.51

line 22

ed

Double quotes used incorrectly, with two sets of close quotes.

XML examples should be given using straight quotes




PT

Part 4, Section 2.18.52

-

te

This type is defined as containing, “a two digit hexadecimal language code”. It is fruther stated that, “This simple type's contents must have a length of exactly 2 characters”. However, two hex digits can count up to 255 and the values enumerated in this clause go far beyond that.


Reconcile the description of the type with the enumerated values.




PT

Part 4, Section 2.18.57

-

te

The description of this type says it contains four hexadecimal digits, four hexadecimal octets and exactly four characters. These definitions are not compatible. A hexadecimal octet is two hexadecimal digits.

Clarify the definition. In particular note that xsd:hexBinary measure length in octets, not characters.




PT




1   2   3   4


The database is protected by copyright ©hestories.info 2017
send message

    Main page