Template for comments and secretariat observations


Part 4, Section 5.1.12.37



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


-

te

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

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




PT

Part 4, Section 5.1.3.2

-

te

No mention is made of what audio formats or codecs are permitted.

An interoperable set of formats should be specified.




PT

Part 4, Section 5.1.3.4

-

te

This describes the attachment of a QuickTime video to a presentation object. No description of the QuickTime format is provided. Without specifying a version and supported codecs, there will be no interoperability.

Provide an external reference for the version(s) of QuickTime format intended here as well as an interoperable codec.




PT

Part 4, Section 6.1


page 4343, line 5

ed

The relationship of 'Other VML namespaces' to the OOXML proposal is unclear.

If the said other namespaces are related to OOXML, clarify the relationship, else remove the reference to them from the text.




PT

Part 4, Section 6.1

page 4343, line 8

te

The reference to 'millions of documents' is an unsupported assertion. Furthermore, it is irrelevant in the context of a standard proposal.

Remove this sentence from the text.




PT

Part 4, Section 6.1

page 4343, line 9

ed

The reference to the specific commercial product 'Office 2000' brings no value to the proposal.

Remove the reference to Office 2000.




PT

Part 4, Section 6.1

page 4343, lines 4&5


ed

What does 'This namespace' refer to? There is no obvious namespace in the context of that sentence.

Clarify.




PT

Part 4, Section 6.1.2.19

pg. 4653 “equationxml”

te

This describes the "equationxml" attribute of "shape" elements, "used to rehydrate an equation using the Office Open XML Math syntax". However, the "actual format of the contents of this attribute are application-defined", which makes them impossible to exchange between applications. If we're going to have a new math markup language in XML, and ignore the existing MathML, let's at least use the new markup in its elemental form, as well-formed XML (not stuffed into an attribute value), and without extending it in application-dependent ways.

Define equations in an interoperable way.




PT

Part 4, Section 6.2.2.14

-

te

This describes an "ink" element which stores "ink annotations in an application-defined format." This is apparently intended to store annotations, used with tablet input devices to add hand-written annotations to documents. These annotations are often a vital part of documents and their specification is undefined in OOXML. We are opposed to standardizing placeholder elements for entirely application-dependent proprietary formats without also specifying an interoperable format for those who with to create interoperable formats.


Specify the “ink” format or remove the element from OOXML and make this an application extension using the extensibility mechanisms of OOXML.




PT

Part 4, Section 6.4.2.10

-

te

This element is defined as providing a, “general-use element for objects that use an image representation, such as OLE objects, embedded controls, cameras and signature lines.” However, the allowed values, EMF, WMF, etc., refer to formats for which no reference has been given.

Provide a proper external normative reference for the allowed formats containable within this element.




PT

Part 4, Section 6.4.3.1

-

te

The allowed values of this enumeration, EMF, WMF, etc., are Windows-specific formats. No allowance seems to have been made for use by other operating systems. For example, in Linux images are typically copied on the clipboard in an open standard format like PNG.

Several options here, but the desire is to allow cross platform interoperability.




PT

Part 4, Section 7.4.2.4


-

te

This defines a new XML string type which allows the inclusion via an escape mechanism of Unicode characters which are otherwise impermissible in XML documents. However, any escape mechanism must also specify a mechanism for “escaping the escape”. So, how does one represent the literal example given in 7.4.2.4 in a bstr?

Complete the definition of the escape mechanism.




PT

Part 4, Section 7.4.2.5

-

te

The value of -3 specifies a GUID that contains a format identifier (FMTID). The required format for neither a GUID nor a FMTID is specified.

Specify this so interoperability may be achieved.




PT

Part 4, Section 7.4.2.5

-

te

This element defines values for use on Windows and Macintosh platforms, but not for Linux or any other operating system.

Several options here, but the desire is to allow cross platform interoperability.


PT


Part 4, Section 7.4.2.5

-

te

Even within a single platform, there is not enough information given to achieve interoperability. For example, what are the allowed values and meanings for a “built-in Windows clipboard format value”?

Specify this so interoperability may be achieved.




PT

Part 4 2.15.2.32, Part 4

6.2.3.17, Part 1 15.2.14,

Part 4, Section 7.4.2.5





te


We should avoid that the proposed standard be, in many ways, platform dependent.

Some behaviors may only be

available on the Windows platform,

and not on Mac, Linux, Unix and

others.

.


It should be guaranteed that there

are no Windows-only features in the proposed standard.









1 MB = Member body (enter the ISO 3166 two-letter country code, and.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


ISO electronic balloting commenting template/version 2001-10



1   2   3   4


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

    Main page