Information about http://www.standard.no/pronorm-3/data/f/0/17/24/1_2401_0/2008-08-31_NO_ISO_IEC_DIS_29500_comments.pdf
Template for comments and secretariat observations …
Tags: annex, dis, justification, legacy documents, paragraph type, referential, scope, secretariat, self reference, succinct overview, vocabularies,Pages: 5
Language: english
Created: Fri Aug 31 10:48:06 2007
Display cached document
Page 1
Page 2
Page 3
Page 4
Page 5
Template for comments and secretariat observations Date: 2007-08-30 Document: ISO/IEC DIS 29500
1 2 (3) 4 5 (6) (7)
MB1 Clause No./ Paragraph/ Type Comment (justification for change) by the MB Proposed change by the MB Secretariat observations
Subclause No./ Figure/Table/ of on each comment submitted
Annex Note com-
(e.g. 3.1) (e.g. Table 1) ment2
NO [Part 1] te Summary: The Scope clause should be rewritten to give a
1 and other succinct overview of the contents of the standard
parts. The Scope clause in Part 1 is inappropriate for an ISO
without self-reference, for example:
standard.
"This International Standard specifies a set of XML
Justification:
vocabularies for representing legacy documents
The Scope clause is self-referential, does not convey any produced by MS Office applications. It covers word
useful information, and does not conform to JTC1 and processing, spreadsheet, presentation and
ISO Directives for the scope of a standard or NP (ref. graphics documents produced by the following
JTC1 Directives, 6.2.1.6; ISO Directives, Part 2, 6.2.1 versions of MS Office applications:
Scope). In the absence of an appropriate Scope clause it [list supported versions]
is not possible to resolve a number of issues arising from
the current text. 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).
NO [ALL] ed Summary: Rework into an ISO-style multi-part standard along
the following lines:
Rework into a multi-part standard.
1. Introduction
Justification:
2. Common/Core components and metadata
As currently drafted, DIS 29500 covers many areas that
are not directly related to one another. This makes it 3. WordprocessingML
difficult to review by National Body experts, difficult to
4. SpreadsheetML
implement, and difficult to assess compatibility.
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.
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 1 of 5
ISO electronic balloting commenting template/version 2001-10
Template for comments and secretariat observations Date: 2007-08-30 Document: ISO/IEC DIS 29500
1 2 (3) 4 5 (6) (7)
MB1 Clause No./ Paragraph/ Type Comment (justification for change) by the MB Proposed change by the MB Secretariat observations
Subclause No./ Figure/Table/ of on each comment submitted
Annex Note com-
(e.g. 3.1) (e.g. Table 1) ment2
NO [ALL] ed Summary: The text should be shortened considerably,
through the removal of non-normative text (into
Rework into a much more concise standard. annexes), the avoidance of redundancy and other
Justification: means.
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.
NO [Part 4] te Summary: Simplify the information model and document
2-7 structure, in order to ease implementation,
The information model is unnecessarily complex. interoperability and the processing of the OOXML
Justification: documents. Where possible use notations in
conformance with ODF.
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.
NO [ALL] te Summary: All examples should be valid XML, except where
there is an express intent to exemplify invalid data.
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.
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 2 of 5
ISO electronic balloting commenting template/version 2001-10
Template for comments and secretariat observations Date: 2007-08-30 Document: ISO/IEC DIS 29500
1 2 (3) 4 5 (6) (7)
MB1 Clause No./ Paragraph/ Type Comment (justification for change) by the MB Proposed change by the MB Secretariat observations
Subclause No./ Figure/Table/ of on each comment submitted
Annex Note com-
(e.g. 3.1) (e.g. Table 1) ment2
NO [Part 1] te Summary: Remove DrawingML from 29500 and propose it as
8.6.1 a separate standard, or commit to doing so at a
DrawingML should be a separate standard later stage.
[Part 4]
Justification:
5
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.
NO [Part 1] te Summary: Remove OPC from 29500 and propose it as a
9.1 separate standard, or commit to doing so at a later
OPC should be a separate standard stage.
[Part 2]
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.
NO [Part 1] te Summary: All references to platform specific and/or binary
15.2.14 notations, such as DEVMODE for printer settings
The specification should not include binary notations. and bitmasks for boolean values, should be
[Part 4] removed and, where possible, replaced by open,
Justification:
2.3.1.6, XML-based standards, more explicit XML
2.4.51, 2.4.52, Unspecified (or underspecified) binary notations, vocabulary, or base64 encoding.
2.4.7, 6.4.3.1, especially those with operating system dependencies,
7.4.2.4, inhibit interoperability and do not belong in an ISO
7.4.2.5, etc. 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.
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 3 of 5
ISO electronic balloting commenting template/version 2001-10
Template for comments and secretariat observations Date: 2007-08-30 Document: ISO/IEC DIS 29500
1 2 (3) 4 5 (6) (7)
MB1 Clause No./ Paragraph/ Type Comment (justification for change) by the MB Proposed change by the MB Secretariat observations
Subclause No./ Figure/Table/ of on each comment submitted
Annex Note com-
(e.g. 3.1) (e.g. Table 1) ment2
NO [Part 4] te Summary: All features should be specified in enough detail to
enable uniform interpretation by multiple
2.15.2.32, The specification should not contain underspecified implementations. Those that cannot be specified in
2.15.3.6, features. sufficient detail should be removed.
2.15.3.26,
Justification:
2.15.3.31,
2.15.3.32, Underspecified features and settings, such as
2.15.3.41, "autoSpaceLikeWord95", "footnoteLayoutLikeWW8",
2.15.3.51, "lineWrapLikeWord6", "mwSmallCaps",
2.15.3.53, "optimizeForBrowser", "shapeLayoutLikeWW8",
2.15.3.54, "supressTopSpacingWP",
2.15.3.63, "truncateFontHeightsLikeWP6",
2.15.3.64, "useWord2002TableStyleRules",
2.15.3.65, "useWord97LineBreakRules",
2.15.3.9, "useWord97LineBreakRules", "wpJustification",
3.2.29, "wpSpaceWidth", "sldSyncPr", "securityDescriptor", and
3.3.1.69, "revisionsPassword" preclude uniform implementation
4.7.1, etc. and thus inhibit interoperability.
NO [Part 4] te Summary: All such features should be made extensible
2.18.4, wherever possible and defined options should be
Option sets should be extensible and should avoid specified in full in order to enable uniform
2.18.66,
cultural bias. implementation.
3.17.7.224,
6.4.3.1, etc. 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.
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 4 of 5
ISO electronic balloting commenting template/version 2001-10
Template for comments and secretariat observations Date: 2007-08-30 Document: ISO/IEC DIS 29500
1 2 (3) 4 5 (6) (7)
MB1 Clause No./ Paragraph/ Type Comment (justification for change) by the MB Proposed change by the MB Secretariat observations
Subclause No./ Figure/Table/ of on each comment submitted
Annex Note com-
(e.g. 3.1) (e.g. Table 1) ment2
NO [Part 4] te Summary: Ensure that 29500 does not conflict with the
2.18.15, above-mentioned standards and use only ISO
OOXML should reference, use, and conform to existing standard date formats, not ambiguous numeric
2.3.2.18,
standards where applicable. dates.
3.2.27,
3.17.4.1, etc. 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.
NO [Part 4] ed Summary: Put in place a coherent value system.
2.18.85, etc.
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.
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 5 of 5
ISO electronic balloting commenting template/version 2001-10