Template for comments and secretariat observations Date: Document:
1 | 2 | (3) | 4 | 5 | (6) | (7) |
MB1 |
Clause No./ Subclause No./ Annex (e.g. 3.1) |
Paragraph/ Figure/Table/Note (e.g. Table 1) |
Type of com-ment2 | Comment (justification for change) by the MB | Proposed change by the MB | Secretariat observations on each comment submitted |
Template for comments and secretariat observations | Date: | Document: ISO/ |
Japan disapproves the proposed DIS 29500 (OOXML), but may change its vote to "approval" if the following comments are resolved satisfactorily.
1 2 (3) 4 5 (6) (7) MB1 Clause No./
Subclause No./
Annex
(e.g. 3.1)Paragraph/
Figure/Table/Note
(e.g. Table 1)Type of com-ment2 Comment (justification for change) by the MB Proposed change by the MB Secretariat observations
on each comment submittedJP1 All parts ge 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. JP2 Part4 Annex A te Apart from MSXML, we find no other validators can handle the W3C XML Schema version of the OOXML schemas. One reason appears to be the import feature of W3C XML Schema. MSXML allows different schema modules to be imported for the same namespace depending on the context, while Xerces-J and MSV do not. Reorganize the schemas so that they can be handled by Xerces-J and MSV at least. JP3 Part 2 Annex B te The "pack" URI scheme is not endorsed by IETF yet. Drop the "pack" URI scheme unless it is endorsed by IETF. JP4 Part 2 Clause 8.1 te Part names are restricted to US-ASCII. Although Annex A describes the conversion from Unicode strings to US-ASCII part names, it is not clear which program provides this conversion. The OPC engine rather than user programs should support the conversion. Allow Non-ASCII characters (or IRIs) as part names. Note that non-ASCII characters can be converted to %HH before constructing logical item names or physical package item names. JP5 Part 4 Clause 8.2.1 te 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. JP6 All parts te Behaviours of application programs are often described using gshallh or gmusth. However, application conformance is defined to be purely syntactical in Section 2.4 of Part 1. From the 6367 occurrences of the word "shall" in Part 4, here we quote some examples of inappropriate use.
- Line 2, Page 27, Part 4, "This background shall be displayed on all 3 pages of the document, behind all other document content".
- The third para in the description for "themeColor", Page 28, Part 4: "its value shall be ignored"
- Line 34, Page 34, Part 4: "This element specifies whether the right indent shall be automatically adjusted".
Use gshallh only for describing constraints on documents or data. Do not use gshallh for describing behaviours of application programs. It might be necessary to use gshallh for describing the behaviours of OPC engines, which should not be confused with application programs. JP7 All parts ed Often gmusth is used as an alternative for gshallh. For example, in Part 4 Clause 2.15.3.6, "To faithfully replicate this behaviour, applications must imitate the behaviour of that applicationc" Do not use this word. See Annex H of ISO/IEC directives Part 2. Moreover, do not mechanically replace gmusth with gshallh. Se JP6. JP8 All parts ed Sometimes "may not" is used to express a prohibition. Do not use this phrase. See Annex H of ISO/IEC directives Part 2. JP9 All parts te 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. JP-10 All parts ed The phrase "element type" is used differently from W3C XML 1.0. Here is an example of confusion caused by the abuse of this phrase: in Clause 8 of Part 1, an element type is a local name rather than a qualified name, and is thus different from element types in XML 1.0. Do not use the phrase "element type", which is a string in XML 1.0. JP-11 All parts ed "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. JP-12 All parts ed "name of an XML element" is not defined. Use "the tag name of an XML element". The phrase "tag name" has been used since W3C DOM Level 1. JP-13 All parts ed "XML element attribute value" is not defined. Use "XML attribute value" or "attribute value". JP-14 All parts ed "XML element attribute" is not defined. Use "XML attribute" or "attribute". JP-15 All parts ed "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". JP-16 All parts (e.g., Page 5 of Part 1) ed "valid" is used in an ambiguous manner. For example what does "valid" in the third paragraph of 2.5.2.6 of Part 4 mean? Do not use the word "valid" when it does not mention validity against some schema. When it does mention validity, always make clear which schema is in question. JP-17 All parts such as Page 18 of Part 1 ed The phrase "tag type" is undefined. Do not use "tag type". JP-18 OFFICE OPEN XML OVERVIEW ge Positioning of this document is not clear. Part 1 Fundamentals does not list the document on page xi. It is unclear whether the document is normative or informative. Clarify the positioning and the status of this document. Section 1 Introduction says, gThis white paper summarizes OpenXML.h If it is not part of DIS 29500, it should not be included in DIS 29500. JP-19 Part 1 ed 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 gtypeh. JP-20 Part 1 ed The phrase "Application Conformance" is misleading, since people will think that behaviours of applications are standardized. Use "Application Syntactical Conformance" instead. JP-21 Part 1 Clause 2 ge 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. JP-22 Part 1 Clauses 2.1 and 2.2 ge Normative statements do not exist in those clauses although clause 7 says, gClauses 1-5, 7 and 9-14 form a normative part of this Part.h ISO/IEC Directives Part 2, 3.8 says that normative elements are those that describe the scope of the document and that set out provisions; 3.9 says that informative elements are those that identify the document, introduce its content and explain its background, its development and its relationship with other documents. Change the status of clauses 2.1 and 2.2 to informative based on ISO/IEC Directives Part 2. JP-23 Part 1 Clause 2.4 Line 22 te 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 gReferencing the Unicode Standards and ISO/IEC 10646h (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: gThe document character set shall conform to the Unicode Standard and ISO/IEC 10646, with either the UTF-8 or UTF-16 encoding form.h Please note that g-1h should be removed from ISO/IEC 10646-1 as the part number is no longer assigned for ISO/IEC 10646, and that gas required by the XML 1.0 standardh 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.)
JP-24 Part 1 Clause 2.6 Lines 33-34 ed It says, "For the guidelines to be meaningful, a software application should be accompanied by publicly available documentation that describes what subset of this Standard it supports..." gpublicly availableh is too strict for applications to follow since it is not always possible for a company to provide publicly available documentation, which sometimes will not be allowed by business needs. Remove gpublicly availableh from the sentence. JP-25 Part 1 Clause 4 Line 13 on page 6 ed The line says, gbehavior, unspecified - Behavior where this Standard imposes no requirements,h which would imply that DIS 29500 specifies application behaviours to some extent. However, clause 2.3 says, gc it is not intended to predefine application behaviorh 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. JP-26 Part 1 Clause 4 and Part 4 ed SGML and XML already define gdocument typeh, but OOXML defines it differently. Do not use this phrase. JP-27 Part 1 Clause 8.3 and Clause 11, Part 3 Clause 2, and Part 4 Clause 2 ge WorprocessingML is scattered into Part 1, 3, and 4. Publish WordProcessingML as a single part of this standard. JP-28 Part 1 Clause 8.4 and Clause 12, Part 3 Clause 3, and Part 4 Clause 3 ge SpreadsheetML is scattered into Part 1, 3, and 4. Publish SpreadsheetML as a single part of this standard. JP-29 Part 1 Clause 8.5 and Clause 13, Part 3 Clause 4, and Part 4 Clause 4 ge PresentationML is scattered into Part 1, 3, and 4. Publish PresentationML as a single part of this standard. JP-30 Part 1 Clause 8.6.6, Part 3 Clause 6, and Part 4 Clause 6 ge Since VML is restricted to legacy features of one particular company (as demonstrated by the namespace of VML and the browser names), it should not be published normatively. Publish VML as a technical report, which is a part of this multi-part standard. Note that a multi-part standard in JTC1 can contain a technical report. JP-31 Part 1 Clause 9.1.1 Line 15 on page 16 ed The sentence gc, where H is hexadecimal digit.]h ends with a closing bracket, but, an opening bracket cannot be found. Remove the closing bracket. JP-32 Part 1 Clause 9.1.7 Line 10 ed The line says, gc where h represents a hexadecimal value.h However, h is a hexadecimal digit as it is specified in 9.1.1. Correct the line by changing value to digit. JP-33 Part 1 Clause 9.2 Line 8 on page 18 ed The line says, gCertain relationships shall be explicit..h A period has been duplicated. Remove the last period. JP-34 Part 1 Clause 10.1.2 Line 20 te The line says, gClause 12 of Part 5 specifies the ability for a markup language to define additional constructs for extensibility of a specific markup languageh while clause 12 of Part 5 specifies, gPreprocessing Model for Markup Consumptionh. Both are inconsistent. Point to the correct clause. JP-35 Part 1 Clause 11.2 Line 9 ed 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. JP-36 Part 1 Clause 11.9 te XSLT transformation is applied only on save ("an XSL Transformation which might be applied on" in 11.9 of Part 1). Why is it not applied on read? JP-37 Part 1 Clause 12.3.5 te Are arbitrary binary data allowed as custom property parts? If so, what is the content type fixed? Allow any content type. JP-38 Part 1 Clause 15.2.15 te The section does discuss the size of Thumbnails. It lacks interoperability with ODF applications. In ISO/IEC 26300 17.6 says, gThe required size for the thumbnails is 128x128 pixel.h Clarify what size of thumbnails should be. JP-39 Part 2 ge 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. JP-40 Part 2 te Conformance to OPC Is not defined. Define conformance to OPC. It probably shouldnft be purely syntactical. Moreover, it might be necessary to separate OPC engines and application programs that rely on OPC engines. JP-41 Part 2 Clause 8.1.4 ed 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. JP-42 Part 2 Clause 8.3.3, 9.1.2.3, and 9.1.2.4 te Assuming that part names are not restricted to US-ASCII, case-insensitive comparison does not work for non-ASCII characters. Use case-sensitive comparison. JP-43 Part 2 Clause 9.1.2.2.4 and Part 1 Clause 11.2 ed 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. JP-44 Part 2 Clause 10 Table 10-1 te Why are "contentTypes" as summarized in Table 10-1 different from MIME content types? If it is really different, choose a different name. JP-45 Part 2 Clause 12 ed 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. JP-46 Part 2 Annex H (Conformance Requirements) ge This informative annex cannot define conformance requirements. Moreover, it is not clear what "conformance requirements" on format designers mean. Change "conformance requirements" to "guidelines", for example. JP-47 Part 4 Clause 1 Line 1 on page 1 ed The usage of gparth in the clause title gPart Overviewh is ambiguous whether it means Part 4 or each part of elements such as WordprocessingML, SpreadsheetML, etc. Remove gparth from the clause title to read gOverview.h Change each part of the elements to subpart. JP-48 Part 4 Clause 2.2.1 Line 8 and line 12 on page 27 te Line 8 says, gc accent5 theme colorh while line 12 shows the attribute value accent3, which is inconsistent. In addition, the table on page 1835 for accent3 does not include a sample of accent3 theme color. It cannot be understood what accent3 should be. Correct the example in 2.2.1 on page 27 and include theme color samples in the table on page 1835. JP-49 Part 4 Clause 2.15.1.28 Line 16 on page 1158 te The line says, gTruncate the password to 15 characters.h 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. JP-50 Part 4 Clause 2.15.1.28 Line 17 on page 1158 te The line says, gConstruct a new NULL-terminated string consisting of single-byte characters.h Do the single-byte characters mean UTF-8 strings which are equivalent to ASCII? Does it imply that Japanese passwords are not allowed? If the restriction exists, it should be clearly documented. Clarify the meaning of gsingle-byte charactersh and the implication. JP-51 Part 4 Clause 2.15.1.28 cryptAlgorithmSid in the table on page 1167 ed The example says, gThe cryptAlgorithmSid attribute value of 1 specifies that the SHA-1 hashing algorithm shall be used to generate a hash from the user-defined password.h 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. JP-52 Part 4 Clause 2.15.3.6 te The layout caused by autoSpaceLikeWord95 (among others) is not clear. Add an example illustrating the document layout, or add a note stating that this is for bug-for-bug compatibility. JP-53 Part 4 Clause 2.16.4.3 THAILETTER on page 1505 ed 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. JP-54 Part 4 Clause 2.16.5.33 te The section does not define how a picture is named. For example, is IRI allowed? Define how a picture is named. JP-55 Part 4 Clause 2.16.5.34 te 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. JP-56 Part 4 Clause 2.16.5.77 Lines 28 through 30 te The example of USERINITIALS shows USERNAME instead of USERINITIALS. Correct the sample to show USERINITIALS. JP-57 Part 4 Clause 2.18.4 earth1 and earth2 on page 1650 te 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. JP-58 Part 4 Clause 2.18.45 Line 6 on page 1738 te The line says, gThis simple typefs contents must have a length of exactly 3 characters.h The hexBinary datatype defined in W3C XML schema is based on octet. One octet consists of 2 characters. g3 charactersh is confusing. The similar errors can be found in the following sections: Part 4, 2.18.52, line 8 on page 1754; Part 4, 2.18.57, line 5 on page 1760; Part 4, 2.18.106, line 13 on page 1837; Clarify the meaning of gcharacter.h Change g3 charactersh to g3 octetsh or to g6 charactersh in the specific clause 2.18.45. Make the similar corrections in the other clauses as well. JP-59 Part 4 Clause 2.18.51 Line 22 on page 1747 ed 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. JP-60 Part 4 Clause 2.18.52 Lne2 on page 1748 te The line says, gits contents will contain a two hexadecimal language codech Two hexadecimal digits mean 8 bits, which allow up to 255 in decimal. The value actually allows the value above 255. Clarify the meaning of hexadecimal. Change it to read ga four hexadecimal language code.h JP-61 Part 4 Clause 2.18.66 aiueo in the table on page 1771 ed 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. JP-62 Part 4 Clause 2.18.66 aiueoFullWidth in the table on page 1771 ed The example shows full-width katakana characters while the description says full-width hiragana characters. Replace the full-width katakana characters with full-width hiragana characters. JP-63 Part 4 Clause 2.18.66 decimalFullWidth, decimalFullWidth2, decimalHalfWidth on page 1773 te The expressions gdouble-byteh and gsingle-byteh 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. gdouble-byteh should be changed to gfull-widthh and gsingle-byteh should be changed to ghalf-width,h respectively, as Arabic 1 is defined as FULLWIDTH DIGIT ONE in Unicode standard. JP-64 Part 4 Clause 2.18.66 aiueo, aiueoFullWidth on page 1771 te It is not clearly defined how to proceed with the numbering after the last alphabetical character. Specify how to proceed with the numbering after the last alphabetical character. JP-65 Part 4 Clause 2.18.66 numberInDash on page 1776 te 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. JP-66 Part 4 Clause 2.18.72 Line 10 and line 21 te Line 10 says g10 hexadecimal digitsh while the example shows 20 hexadecimal digits in line 14. Line 21 says g10 charactersh while the example shows 20 characters in line 14. They conflict with the hexBinary datatype defined in W3C XML schema. The similar errors can be found in the following sections: 3.18.86 on page 2930, 3.18.87 on page 2930, 5.1.12.28 line 7 on page 3700.. Change g10 hexadecimal digitsh to g20 hexadecimal digitsh in line 10, and change g10 charactersh to g20 charactersh in line 14, respectively. Make the similar corrections in other clauses. JP-67 Part 4 Clause 2.18.86 Line 1 and line 5 on page 1809 te Line 1 says gtwo hexadecimal octetsh which means HHHH as one octet is represented as HH in hexadecimal. It is 4 characters while line 5 says g2 characters.h The definition is confusing. Clarify the definitions. Change gtwo hexadecimal octetsh in line 1 to gfour hexadecimal digitsh as other sections, e.g. 2.18.106, specify. Change g2 charactersh in line 5 to g4 characters.h JP-68 Part 4 Clause 3.2.29 revisionsPassword attribute on page 1916, workbookPassword on page 1922 te The pre-process that Unicode UTF-16 input code points are converted to an gansih single or double-byte code page has been specified. For example, code page 932 is used for Japanese. Converting input characters from UTF-16 to code page 932 will cause a character loss problem since code page 932 does not support level 3 and 4 Japanese characters defined in JIS X 0213. Code page 932 supports only JIS X 0208. And for the historical reasons, conversion from UTF-16 to code page 932 differs among vendors. The pre-process is harmful in interoperability. The similar problem will happen with Chinese support when UTF-16 characters are converted to code page 936 since GB 2312 is only supported and GB 18030 is not supported in code page 936. Also, the expression g16-bit Unicodeh is confusing. It is not clear if it means that BMP is only supported and that surrogate Unicode characters are not supported. To support JIS X 0213 and GB 18030 characters, surrogate Unicode characters are to be supported. The similar pre-process is defined in 3.3.1.69 on page 2003. Allow all UTF-16 characters to be used. JP-69 Part 4 Annex A te 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. JP-70 Part 4 Annex B and Part 2 Annex E te The RELAX NG version of the OOXML schemas is syntactically incorrect. Replace it by the upcoming proposal from the Japanese member body for SC34. JP-71 Part 4 Annex B and Part 2 Annex E te 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. JP-72 Part 4 Clause 2.18.51, etc. te While two-letter ISO 639-1 language codes are allowed, three-letter ISO 639-2 language codes are disallowed. Use RFC 4646 for defining language codes. JP-73 Part 4 Clause 2.5.1 and Clause 2.5.2 te 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. JP-74 Part 4 Clause 3.16 te The Custom XML Mappings Part of the SpreadsheetML is restricted to W3C XML Schema. Allow the use of RELAX NG. JP-75 Part 4 Clause 5 te 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. JP-76 Part 4 Clause 8.2.1 te The semantics of the attribute "manifestLocation" of the element "w:schema" is unclear. What is a resource file? JP-77 Part4 Annex A te Some definitions are duplicated in more than one schema modules. (A list of definitions having the same name is attached.) Such duplications are particularly harmful, when the duplicated definitions are changed inconsistently in the future. A good example is the simple type "ST_Guid", which has a rather complicated pattern facet "*{[0-9A-F]{8}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{12}*}". This simple type is defined five times by dml-baseTypes.xsd,shared-customXmlDataProperties.xsd, sml-baseTypes.xsd, vml-officeDrawing.xsd, and wml.xsd. They are likely to be changed inconsistently in the future. Reorganize the schemas so that no definitions are duplicated. JP-78 Part4 Annex A te The schema wml.xsd is too large. Modularize this schema. In particular, when different parts have different root elements, different schemas should be provided. JP-79 Part 5 ge Since Markup Compatibility is technically independent from the rest of OOXML, it should become an independent standard. Publish Markup Compatibility as an independent standard. JP-80 Part 5 te Conformance to Markup Compatibility Is not defined. Define conformance to Markup Compatibility. It probably shouldnft be purely syntactical. Moreover, it might be necessary to separate OPC engines and OPC application programs. JP-81 Part 5 Clause 10.1.1 and Part 1 Clause 10.1.1 te PreserveElements and PreserveAttributes are defined but they are not used by OOXML. To avoid premature standardization, it should be standardized later. Do not introduce PreserveElements and PreserveAttributes. JP-82 Part 5 Bibliography ed The ISO/IEC number of NVDL is incorrect. Replace 197575-4 by 19757-4.
1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **)
2 Type of comment: ge = general te = technical ed = editorial
NOTE Columns 1, 2, 4, 5 are compulsory.
page of 16
ISO electronic balloting commenting template/version 2001-10
1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China) ** = ISO/CS editing unit
2 Type of comment: ge = general te = technical ed = editorial
NB Columns 1, 2, 4, 5 are compulsory.
page of 16
FORM 13B (ISO) version 2001-09
|
![]() |
|