Template for comments and secretariat observations

:)


Download 299.49 Kb.
Page3/4
Date conversion09.07.2018
Size299.49 Kb.
1   2   3   4
Part 4, Section 2.18.66


“decimalEnclosedFullstop”

te

The example given does not show enclosed characters and so contradicts the normative text.

Reconcile the text and the example.




PT

Part 4, Section 2.18.66

“decimalFullwidth”, etc.

te

There are several mentions of double-byte and single-byte Arabic numbering schemes. Since the conformance clause for OOXML requires the use of Unicode in UTF8 or ITF16 encodings, there should be no mention of other encodings.

Reconcile the text and the conformance clause..




PT

Part 4, Section 2.18.66

“lowerLetter”, etc.

te

Several counting systems are defined to use letters of the alphabet, but nothing is mentioned about how counting continues once the letters of the alphabet are exhausted.

Clarify the text to explicitly cover this case.




PT

Part 4, Section 2.18.66


“numberInDash”, etc.

te

Format requires use of “dash” to surround the number, but no indication of which Unicode dash is intended, en-dash, em-dash, hyphen-minus, figure-dash, quotation-dash, etc.

Specify the intended dash explicitly.




PT

Part 4, Section 2.18.72

-

te

No definition is provided for a “Panose-1 classification” of a font.

Provide a proper external normative reference for this term.




PT

Part 4, Section 2.18.72

-

te

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

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




PT

Part 4, Section 2.18.85

-

te


The fill patterns lack definitions. The illustrations given are insufficient. An application needs to know what in these illustrations are required behaviors and what are not. For example, is the exact dithering pattern used in the illustration required?

Provide full normative definitions for these graphical elements.




PT

Part 4, Section 2.18.86

-

te

The description of this type says it contains two hexadecimal digits, two hexadecimal octets and exactly two 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

Part 4, Section 2.2 Main Document Story

page 26, lines 24&27

te

These lines define the contents of an OOXML document of type Wordprocessing in terms that are not compatible with the definition of OOXML documents given in Part 1, Section 4. Definitions, page 7, lines 1 to 3. Note that Section 2.2 as a whole is affected by that inconsistency.

Rewrite or remove Section 2.2. May consider explaining what a OOXML story would be in terms of documents renditions by applications.





PT

Part 4, Section 2.2 Main Document Story

page 26, lines 27&28

te

The definition of 'story' is inappropriate. We shouldn't be defining a markup standard in application terms. We should be defining markup in markup terms. Where the user can type is immaterial.

Clarify the definition of 'story'.




PT

Part 4, Section 2.2.1

page 28, line 1

te

The sentence 'or auto to allow a consumer to automatically determine the background color as appropriate.' does not define the appropriate behavior of the consumer, whereas the definition of the corresponding simple type, found in Part 4, page 1737, explicitly states that 'This value shall be used to specify an automatically determined color value, the meaning of which is interpreted based on the context of the parent XML element.'

Define the characteristics of the auto value for the color attribute of the background element properly.




PT

Part 4, Section 2.2.1

page 29, line 0

te

There are several instances of the word 'border' that are meaningless in this context (the text is supposed to describe the 'background' element at that location and no “border” has been defined).

Clarify which border the text refers to (if any notion of border must be introduced here) or else rewrite the text so that it makes sense.




PT

Part 4, Section 2.2.1 background (Document Background)

page 27, lines 1&2

te

Assuming that background be referring to the background of the document defined by one of its enclosing elements, assuming that the notion of document page and the notion of displaying be properly defined and that their definitions match commonly accepted ones, then the 'This background shall be displayed on all pages of the document, behind all other document content.' sentence makes unclear whether the total surface of a page must be filled with the background, or else how the subpart of the said surface can be determined.

Clarify the definition of 'background'.




PT

Part 4, Section 2.2.1 background (Document Background)


page 27, lines 8&21

te

Contradicting use of accent3 and accent5 – the text says one thing, but the example says another.

Fix the contradiction.




PT

Part 4

Section 3.17.4






te

The display of dates is limited the lowest date of 1900, no dates before that can be represented, and dates up to 29 February 1900 are displayed with an error. An ISO standard should not be mandating incorrect values for the well-established Gregorian Calendar. To do so will only lead to confusion, poor interoperability and perpetuation of errors.

There are also two methods for displaying dates (1900 and 1904) that do not help clarifying the specification. There is no clear advantage to having two slightly different systems, and this brings significant costs and confusion, as illustrated by the need to specify a default base system, etc.



Allow a range of vendor-declared date bases, or explicitly allow negative date serial values to express dates prior to 1900.

Fix date limitations and if there is no other solution, choose to implement ISO 8601 for displaying dates using the Gregorian Calendar.

If needed for legacy reasons with legacy Excel documents, then introduce an additional vendor-specific tag such as “doWrongDateCalculationsLikeExcel” or similar. This is the approach recommended elsewhere in OOXML for legacy Word features.






PT

Part 4, Section 3.17.4.1

page 2522, lines 16&18

te

The documented upper limits for serial date times match 9999-12-31 00:00:00, which is most probably not what was intended. The expected upper limits would match 9999-12-31 23:59:59.

Clarify the upper limits.




PT

Part 4, Section 3.18.86

-

te

Length is said to be “exactly 4 characters”. This is inconsistent with the schema fragment given which defines it as being 4 octets long or 8 characters.

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




PT

Part 4, Section 3.18.87

-

te

Length is said to be “exactly 2 characters”. This is inconsistent with the schema fragment given which defines it as being 2 octets long or 4 characters.

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





PT

Part 4

Section 7.1






te

This is the specification of Office Open Math Markup Language, a specialized XML vocabulary for the describing the layout of mathematical equations. This solves the same problem as MathML, a long-established W3C standard and an ongoing activity in the W3C.

Adoption of this standard could improve/simplify interoperability with other applications and especially with players in science/scientific research.



It is recommended that this section be specified in compliance with the W3C MathML standard for displaying maths equations.

It is recommended that OOXML work with the W3C's MathML activity, where MathML 3.0 is currently being drafted, to produce a single standard for equations that can be used later referenced by a future version of OOXML.







PT

Part 4

Section 2.15.1.28






te

The specific algorithm for protecting documents does not comply with any known standard.

The hash algorithm provided, is likely based on a legacy algorithm used in Word. This legacy algorithm is known to be a weak algorithm and has effectively been cracked. One could argue that no hash algorithm would be effective in OOXML, since a user could simply unzip the document and hand edit the XML to remove the hash or to set it to some known value. However, some application types such as online editing via Google Docs, or other similar applications, can secure physical access to the document via other means. Editing access to the document does not necessarily presuppose physical access to the document's XML. So there is a necessity for a secure & interoperable hash algorithm, such as SHA-256 for document protection.

While it is not mandatory to represent this algorithm using another standard one, taking into account the security issues that today obstruct an organization’s everyday operations, a proven security approach should be considered with a proven encryption standard.


Use a standard, FIPS-180 compliant hash algorithm as the default (such as the SHA-256 encryption standard). Legacy hash algorithms should be supported via the described extension mechanism.

Likewise, other algorithms mentioned in the specification and known to be less secure could equally be improved (see next comment).






PT

Part 4, Section 3.2.29,

Part 4, Section 3.3.1.69



-

 te

A hash algorithm is provided, likely based on a legacy algorithm used in Excel. This legacy algorithm is known to be a weak algorithm and has effectively been cracked. One could argue that no hash algorithm would be effective in OOXML, since a user could simply unzip the document and hand edit the XML to remove the hash or to set it to some known value. However, some application types such as online editing via Google Docs, or other similar applications, can secure physical access to the document via other means. Editing access to the document does not necessarily presuppose physical access to the document's XML. So there is a necessity for a secure & interoperable hash algorithm, such as SHA-256 for document protection.

Use a standard, FIPS-180 compliant hash algorithm (such as the SHA-256 encryption standard), as the default. Legacy hash algorithms should be supported via the described extension mechanism.


PT


Part 4, Section 3.2.29

p. 1917-1922

te

No normative description of the password hashing algorithm is provided, so interoperability of this feature cannot be assumed. In an informative section, 5-pages of C-language source code is provided as “an example”, and this appears to involve machine-dependent bit manipulations.

Provide a normative, cross-platform definition of the hashing algorithm. Cross-platform source code can be given as an example, but the normative text should be in English, not in a programming language.




PT

Part 4, Section 3.2.29

pg. 1916

te

This seems to imply that if a password is entered in a script like Armenian or Ethiopic then the characters will be replaced all by a single character 0x3F, making the protection feature useless. This is unacceptable.

Remedy so password hashes can be calculated on any Unicode password.




PT

Part 4, Section 3.2.29

pg. 1916

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 3.2.29

pg. 1916

te

The conversion from input password to single byte string is ambiguous. Certainly the input password could contain characters from more than one script, say some Korean, some Chinese. Do we process via multiple DBCS code pages? Or just one and then replace the unmapped characters with 0x3F? If only one DBCS code page is used, how is that determined in this case?

Clarify this processing, especially for passwords that use characters from more than one script.




PT

Part 4, Section 3.3.1.61


-

te

The pageSize attribute allows a set of enumerated values which does not encompass all of the page size values permitted by ISO 216, ANSI Y14.1 and similar DIN and JIS standards.

Rather than trying to maintain a paper size registry, a more flexible approach would be to simply record the dimensions of the paper size selected.




PT

Part 4, Section 3.3.1.69

-

te

The securityDescriptor attribute, “defines user accounts who may edit this range without providing a password to access the range”. It is a string. But no information is given as to what user accounts are referred to here, or what the delimiter is. Are these comma-delimited local machine user accounts? Or semi-colon delimited LDAP DN's? There will be no interoperability if this is not defined.

Fully define this attribute.




PT

Part 4, Section 5.1.12.28

-

te

This type is used in only two places, 5.1.2.2.32 and 5.1.2.2.33, in both cases to represent an RGB color value. Since you already have defined a ST_HexColorRGB type that should be used.


Use the ST_HexColorRGB type and remove ST_HexBinary3




PT

Part 4, Section 5.1.12.28

-

te

Length is said to be “exactly 3 characters”. This is inconsistent with the schema fragment given which defines it as being 3 octets long or 6 characters.

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




PT

Part 4, Section 5.1.12.37

-

te

No definition is provided for a “Panose setting of a font”.

Provide a proper external normative reference for this term.




PT

Part 4, Section 5.1.12.37

-

te

The Panose value is said to be used, “so that generating applications using this Office Open XML Standard may determine the closest font type if necessary”. However, no font distance metric or font matching heuristic is described.

Describe the intended font matching procedure.





PT

Part 4, Section 5.1.12.37

-

ge

Why are there several different definitions for a Panose value, both in Word Processing ML as well as Drawing ML?

Since they are exactly the same they should be defined once in a shared schema.




PT




1   2   3   4
:)


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

    Main page

:)