DIS29500 appears to be competing and incompatible with OASIS sourced ISO/IEC 26300 "Open Document Format for Office Applications."

In order to secure interoperability between the International Standards, Japan believes that JTC 1 should play a leading role in the future in collaboration with Ecma and OASIS. Thus Japan would like to confirm Ecma and its core members' collaborative stance with JTC 1 for the maintenance and the future evolution of DIS29500 upon its approval under the JTC 1 process. In particular, JTC1 rather than Ecma should maintain OOXML.

The "pack" URI scheme is not endorsed by IETF yet.

Drop the "pack" URI scheme unless it is endorsed by IETF.

Custom schemas can be written only in W3C XML Schema, which is merely one of the several schema languages. SC34 has standardized RELAX NG, Schematron, and NVDL among others.

Allow schema languages other than W3C XML Schema for the validation of Custom XML and Structured Document Tags.

Often “must” is used as an alternative for “shall”. For example, in Part 4 Clause 2.15.3.6, "To faithfully replicate this behaviour, applications must imitate the behaviour of that application…"

Do not use this word. See Annex H of ISO/IEC directives Part 2. Moreover, do not mechanically replace “must” with “shall”. Se JP6.

Mandatory specifications such as XML, namespaces, Dublin Core Element Set, and RFCs for URIs and IRIs are only shown in the bibliography.

They should be added in the list of normative references. Note that ISO/IEC 15836:2003　Information and documentation - The Dublin Core metadata element set is equivalent to Dublin Core Metadata Element Set V1.1.

"Schema" and "XML schema" are ambiguous, since W3C XML Schema is merely one of the several XML schema languages.

Always write "W3C XML Schema" when this particular schema language is meant. "Schema" and "XML schema" refer to any schema language such as RELAX NG.

"XML element attribute value" is not defined.

Use "XML attribute value" or "attribute value".

"XML element type name" is extremely confusing. Those who have carefully read the W3C XML 1.0 specification will think that an "XML element type name" is a tag name.

If this phrase references to the name of a simple datatype, use "datatype name of an XML element".

The phrase "tag type" is undefined.

Do not use "tag type".

Unfortunately, there are at least three different definitions of types (XML, W3C XML Schema, and MIME) already. OOXML (vaguely) introduces yet another definition of types. The confusion is demonstrated by the example at the bottom of Page 25 of Part 1.

The relationship in question specifies "http://schemas.openxmlformats.org /officeDocument /2006/relationsihps/officeDocument"

as the "type" of document.xml. However, we already have three types (shown below) for the root element of document.xml.

• The element type (as defined by W3C XML) of this element is "w:document".

Note: Surprisingly enough, element types are never clearly defined by the XML recommendation. Here we follow the interpretation of one of the editors of the XML recommendation and assume that element types are strings.

• The complex type of this element is "CT_Document", which is specified in wml.xsd.
• The content type of this part is application/vnd.openxmlformats -officedocument .wordprocessingml.document .main+xml.

Do not introduce yet another definition of the word “type”.

Document conformance as defined in Part 1 looks too general and has nothing specific to WordprocessingML. However, for a document to conform to WordprocessingML, it has to satisfy requirements stated in Part1 Clause 11, Part 2, and Part 4 Clause 2, at the very least. It is not clear whether requirements stated in other places also have to be satisfied.

Define document conformance for Word-Processing in the part defining WordprocessingML. The same change request applies to document conformance for SpreadsheetML and PresentationML.

Line 22

The line specifies conformance to the Unicode standard and ISO/IEC 10646. There is discrepancy between the Unicode standards required by XML 1.0 standard and the Unicode standard version 4.0 specified in Part 1 Annex A.

Follow the generic reference as described in W3C recommendation “Referencing the Unicode Standards and ISO/IEC 10646” (http://www.w3.org/TR/ charmod/#sec-RefUnicode) as the versions do not have to be restricted in DIS 29500, and change line 22 as follows: “The document character set shall conform to the Unicode Standard and ISO/IEC 10646, with either the UTF-8 or UTF-16 encoding form.” Please note that “-1” should be removed from ISO/IEC 10646-1 as the part number is no longer assigned for ISO/IEC 10646, and that “as required by the XML 1.0 standard” should be removed since the way that the Unicode Standard is referred to in XML 1.0 standard does not follow the W3C recommendation. Also, change lines 19-20 in Annex A as follows:

Unicode

The Unicode Consortium, The Unicode Standard, Version 5, ISBN 0321480910, as updated from time to time by the publication of new versions. (See

http://www.unicode.org/unicode/ standard/versions for the latest version and additional information on versions of the standard and of the Unicode Character Database).

ISO/IEC 10646

ISO/IEC 10646:2003, Information technology - Universal Multiple-Octet Coded Character Set (UCS), as, from time to time, amended, replaced by a new edition or expanded by the addition of new parts. (See

http://www.iso.org/iso/en/ ISOOnline.openerpage for the latest version.)

Line 13 on page 6

The line says, “behavior, unspecified - Behavior where this Standard imposes no requirements,” which would imply that DIS 29500 specifies application behaviours to some extent. However, clause 2.3 says, “… it is not intended to predefine application behavior” meaning that DIS 29500 does not define application behaviors. Thus, the definition is conflicting.

Clarify the definition. It would probably mean that behavior for which this Standard does not make a recommendation.

WorprocessingML is scattered into Part 1, 3, and 4.

Publish WordProcessingML as a single part of this standard.

PresentationML is scattered into Part 1, 3, and 4.

Publish PresentationML as a single part of this standard.

Line 15 on page 16

The sentence “…, where H is hexadecimal digit.]” ends with a closing bracket, but, an opening bracket cannot be found.

Remove the closing bracket.

Line 8 on page 18

The line says, “Certain relationships shall be explicit..” A period has been duplicated.

Remove the last period.

Line 9

The reference to the clause of Thumbnail is incorrect. Currently, §15.2.14 is specified while the correct one is §15.2.15. The other incorrect references can be found in the following pages: line 32 on page 47, line 13 on page 60, line 7 on page 94, line 25 on page 98, line 24 on page 105, line 6 on page 107, line 25 on page 108, line 26 on page 110, line 10 on page 113, line 1 on page 115, line 18 on page 116, and in the table on page 137.

Correct the clause number referred from 15.2.14 to 15.2.15.

Are arbitrary binary data allowed as custom property parts? If so, what is the content type fixed?

Allow any content type.

Since OPC is technically independent from WordprocessingML, PresentationML, SpreadsheetML, VML, DrawingML, and Shared MLs, it should become an independent standard.

Publish OPC as an independent standard.

It is not clear if restrictions in 8.1.4 (e.g., Unicode only and no DTDs) apply to only those parts defined in OPC or do they also apply to parts designed by format designers. Can users create a Shift_JIS XML document containing a DTD and incorporate it in a package?

If the restrictions do not apply only to those parts defined in OPC, explicitly state that format designers can design parts freely.

The element name "Types" is very confusing.

Use "ContentTypes". If this change is not possible, there should be some notes about this inappropriate name at the very least.

Some normative things are copied from the W3C Recommendations "XML-Signature Syntax and Processing" and even modified.

Do not copy or restate normative things but merely reference to them, since they may be updated in the future. There should be no modifications other than subsetting.

Line 1 on page 1

The usage of “part” in the clause title “Part Overview” is ambiguous whether it means Part 4 or each part of elements such as WordprocessingML, SpreadsheetML, etc.

Remove “part” from the clause title to read “Overview.” Change each part of the elements to subpart.

Line 16 on page 1158

The line says, “Truncate the password to 15 characters.” If the password is less than 15 characters, what process, e.g. padding by zero, will be done?

Clarify the process if the password length is less than 15 characters.

crypt Algorithm Sid in the table on page 1167

The example says, “The cryptAlgorithmSid attribute value of 1 specifies that the SHA-1 hashing algorithm shall be used to generate a hash from the user-defined password.” However, the attribute value of 1 means MD2 and 4 means SHA-1 in the table above the example.

Change the attribute value from 1 to 4.

THAILETTER on page 1505

The example shown for THAILETTER is not consistent with the thaiLetters example shown on page 1777.

Change the example in 2.16.4.3 as shown in the example on page 1777.

The section does not define how text is named while there exit only a couple of examples. For example, is IRI allowed?

Define how text is named.

earth1 and earth2 on page 1650

The images of earth1 and earth2 do not include Asia regions such as Japan, Korea, Vietnam, etc. It does not provide means for Asia users to customize those images. Also, it is not clear if those images are normative or informative. The similar comment can be addressed to the pattern images defined in 2.18.85.

Provide means to customize the images. Clarify the images defined in clause 2.18.4 and clause 2.18.85 are normative or informative.

Line 22 on page 1747

The double quotation marks surrounding en-CA are different from the double quotation marks used in other example, e.g. line 2 on page 1744.

Correct the double quotation marks.

aiueo in the table on page 1771

The example shows half-width katakana characters while the description says hiragana characters that must be distinguished from half-width katakana.

Replace the half-width katakana characters with hiragana characters.

decimal Full Width, decimal Full Width2, decimal Half Width on page 1773

The expressions “double-byte” and “single-byte” are confusing while they are encoded in 3 bytes in UTF-8. For example, Arabic 1 used in example is encoded in 0xEFBC91 in UTF-8.

“double-byte” should be changed to “full-width” and “single-byte” should be changed to “half-width,” respectively, as Arabic 1 is defined as FULLWIDTH DIGIT ONE in Unicode standard.

numberInDash on page 1776

There are several dash characters whose shapes are similar each other in Unicode standard. For example, Unicode standard defines HYPHEN-MINUS (U+002D), HYPHEN (U+2010), NON-BREAKING HYPHEN (U+2011), FIGURE DASH (U+2012), EN-DASH (U+2013), HORIZONTAL BAR (or QUOTATION DASH U+2015), and MINUS SIGN (U+2212). It is not clear that all dash characters are allowed or there are any restrictions.

Clarify the Unicode code points that are allowed for numberInDash value in ST_NumberFormat.

Line 1 and line 5 on page 1809

Line 1 says “two hexadecimal octets” which means HHHH as one octet is represented as HH in hexadecimal. It is 4 characters while line 5 says “2 characters.” The definition is confusing.

Clarify the definitions. Change “two hexadecimal octets” in line 1 to “four hexadecimal digits” as other sections, e.g. 2.18.106, specify. Change “2 characters” in line 5 to “4 characters.”

Validation against the VML schemas cannot be separated from that against the rest of OOXML. In other words, a WordprocessingML document cannot be validated without performing validation against the VML schemas.

Specify "skip" as the value of "processContents" attribute.

Since W3C XML Schema very frequently exhibits interoperability problems, it is not safe to use it as the only normative schema language.

Use both RELAX NG and W3C XML Schema normatively.

The differences between smart tags, custom XML markups, and structured document tags are unclear. In particular, 2.5.1 (Custom XML and Smart Tags) and 2.5.2 (Structured Document Tags) of Part 4 are almost the same.

Clarify the differences. Some tutorial (e.g., as a non-normative appendix) would be very helpful.

The import and include relationships among the DrawingML schemas are extremely complicated. (See http://www.asahi -net.or.jp/ ~eb2m-mrt/ ooxml/ dependencies.html.)

To make the relationships more understandable, it might make sense to divide DrawingML into sublanguages or introduce some text and diagrams on the relationships of DrawingML schemas.