Talk:EOOXML objections

From Grokdoc

This page is for discussion of the EOOXML objections, including any potential problems that you find in the Ecma 376 standard, or concerns about the wording of the objections. To add a new topic for discussion, click the "+" tab next to the "edit" tab at the top of the page.

The EOOXML objections page is now locked to prevent editing. If you find further flaws in Ecma 376, please add them to:

• EOOXML Objections Clearinghouse

Contents 1 British Standards Institute 2 JTC 1 Directives 2.1 13 Preparation and Adoption of International Standards - Fast-Track Processing 2.2 M.7.4.3.3 Substitution and Replacement 3 International Numeric Formatting Standards? 4 INCLUDEPICTURE 5 Audio and Video part formats 6 "Application-defined" defaults? 7 Equation shape objects in drawings are not editable unless you are Microsoft? 8 "Application-defined" binary blobs within shape objects? 9 "Application-defined" binary blobs for Microsoft Ink™ data? 10 Bitmasks are not subject to endian issues when represented as numeric strings 11 ST_Panose defined twice 12 Multiple types used for RGB coding 13 cryptography and fields 14 Paper Sizes 15 Uses a Microsoft-specific namespace 16 A string is used to define deprecated VML in DrawingML 17 Ecma 376 contradicts SVG colour names 17.1 SVG color values 18 Legacy Information 18.1 Preset Color 18.2 "Application-defined" and undefined "legacy" merge document formats? 18.3 Another undefined "legacy" feature: the DigSig element 19 Microsoft Office names 19.1 VML and DrawingML 20 OOXML defines two *different* hashing algorithms 21 Does nobody know wikiquette? 22 The whole ISO 639 issue is not correct 23 OOXML does use standard dates. 24 Licensing 25 The ISO/IEC 8632 (Computer Graphics Metafile) issue. More FUD 26 Poor semantics in Licensing discussion 27 Patent claim 28 Objections against examples ??? 29 A TWIPpy objection ??? 30 Bitmasks cause significant validation problems 31 Non XML formatting codes 32 Submission form for objections to Standards Australia, due 21 August 33 Does Office 2007 use (E)OOXML

British Standards Institute

The BSI is a P member on the JTC commitee and therefore has the ability to to halt the fast track process of EOOXML.

The BSI is governed under the following rules:

The Royal Charter

The Formal Memorandum of Understanding

The Public Policy Interest in the UK, Part 1

The Public Policy Interest in the UK, Part 2

And must follow 'BS 0, A Standard for Standards"

Part 1, Development of Standards - Specification Part 2, Structure and Drafting - Requirements and Guidance

There are many provisions in these documents that indicate that the BSI should not aprove the fast-tracking of EOOXML. Here are some extracts from the first 4 listed above (the foundation documents of the BSI):

“BSI has committed to the UK government that it will take into account the UK public policy interest in conducting its NSB activities.”(BS0)

“British Standards, including standards formulated in ... international contexts ... are developed ... to serve the UK public policy interest” (MOU 1.4)

“..Companies themselves can have an incentive to .. promote their own specifications and exclude competition, perhaps by forming cartels.” (or monopolies) “Public Policy is required in order to compensate for these market imperfections.” (MOU 2.2.4)

“The Government and BSI are ... determined to promote effective standardisation policy in order to realise in full the potential socio-economic benefits of standardisation, including the promotion of the small and medium sized business sector and of ... consumer ... interests.” (MOU 2.4)

“BSI will ensure ... that it achieves ... the optimal promotion of UK interests”. (MOU 4.1.3)

And here is a very interesting snippet from BS 0, A Standard for Standards:

"Where BSI as the UK NSB has approved an international draft standard, the published standard shall be adopted as a national standard except in the following cases: • where the international standard is being adopted as a European standard; or • where there is an existing conflicting European standard; or • where there is an existing national standard which the Technical Committee considers is more appropriate for the UK."

Searching the BSI standards database gives the following result which indicates that ODF is already a British Standard. Need to follow this up to ensure that it is correct.

"BS ISO/IEC 26300 (2005/02775) BS ISO/IEC 26300 Information technology - Open Document Format for Office Applications (OpenDocument) v1.0"

Based upon the the above provision, this could preclude OOXML becoming a British standard on the basis of it conflicting with ODF.

BS 0(2) states: "7.8.2.3 Normative Reference to Documents other then Public Standards.

Normative reference shall not be made to material that is: - not publicly available; - not readily accessible; - known to be of unstable or ephemeral nature."

(The text does not state whether these are AND or OR provisions, but is clearly would not make sense for a reference to be excluded only if all 3 of the above conditions were met).

This passage would seem to be in direct conflict with the EOOXML specification's reliance on material external to the specification(ie the behaviour of MS Word 6)

I haven't read all of BS 0 yet, nor uploaded all of my quotes from the 'foundation documents' of the BSI

JTC 1 Directives

13 Preparation and Adoption of International Standards - Fast-Track Processing

13.2 The proposal for the fast-track procedure shall be received by the ITTF which shall take the following actions:

• Settle the copyright or trademark situation, or both, with the proposer, so that the proposed text can be freely copied and distributed within ISO/IEC without restriction;

• Assess in consultation with the JTC 1 Secretariat that JTC 1 is the competent committee for the subject covered in the proposed standard and ascertain that there is no evident contradiction with other ISO/IEC standards;

• Distribute the text of the proposed standard (or amendment) as a DIS (or DAM), indicating that the standard belongs in the domain of JTC 1 (see Form G12). In case of particularly bulky documents the ITTF may demand the necessary number of copies from the proposer.

13.5 During the 30-day review period, a NB may identify to the JTC 1 Secretariat any perceived contradiction with other JTC 1, ISO or IEC standards.

If such a contradiction is alleged, the matter shall be resolved by the ITTF and JTC 1 Secretariat in accordance with Section 13.2 before ballot voting can commence. If no contradiction is alleged, the fast-track ballot voting commences immediately following the 30-day period.

M.7.4.3.3 Substitution and Replacement

a) What needs exist, if any, to replace an existing international standard? Rationale?
b) What is the need and feasibility of using only a portion of the specification as an international standard?
c) What portions, if any, of the specification do not belong in an international standard (e.g. too implementation- specific)?
(Annex M The Transposition of Publicly Available Specifications into International Standards)

---

International Numeric Formatting Standards?

In section 2.16.4.3 (p. 2283), a number of formatting strings are defined to specify how numbers are printed, such as "CHOSUNG" to use Korean Chosung format, or "CHINESENUM2" to use the Chinese simplified legal format, etc. Surely there is a more general standard for this sort of thing? Stevenj 22:30, 19 January 2007 (EST)

Whats even worse, its similar to Inflexible Numbering format (p 2554) which is a redefinition. I originally had the 2.16.4.3 included in this concern, but somehow its not there anymore... Its a seperate issue to 'infexible', but its anther concern where number-formats are defined multiple times within the same spec. One its by a enumValue (p 2554), and the other (p. 2283) is a ?? enum? string? --- Yoonkit 23:10, 22 January 2007 (EST)

INCLUDEPICTURE

On page 2320, section 2.16.5.33, it defines a field INCLUDEPICTURE that can be used to insert a "picture" from an external file:

Retrieves the picture contained in the document named by field-argument. If field-argument contains white space, it shall be enclosed in double quotes. If field-argument contains any backslash characters, each one shall be preceded directly by another backslash character.

However, it doesn't seem to define what kinds of "picture" file formats should be supported. (It gives an example of a .jpg file, presumably some version of the JPEG standard.)

Stevenj 23:05, 19 January 2007 (EST)

Audio and Video part formats

Section 15.2.2 (p. 148) describes an "Audio Part" which may "contain an audio file" and be of "any supported audio type" and which "may be the target of a relationship in a Handout Master, Notes Slide, Notes Master, Slide, Slide Layout, or Slide Master part-relationship item. The standard does not specify, however, what audio file types (if any) are to be supported by a conforming application. It gives examples of AIFF, WMA, and MIDI files.

Similarly, section 15.2.16 (p. 167) defines a "Video Part" which "contains a video file" of "any supported video type", which can also be the target of a relationship in slides, etc. Again, it does not specify what video file types must be supported (it gives examples of AVI, MPEG, QuickTime, and Windows Media files).

(See also section 5.1.3, page 4073, which specifies how audio and video of arbitrary unspecified types can be embedded in DrawingML.)

I'm of two minds about this. On the one hand, if I'm using a Mac and my OOXML implementation uses QuickTime, it's certainly nice to be able to embed audio and video in any file format that happens to be supported by QuickTime. On the other hand, what good is a standard format for presentations if there is no guarantee that anyone will be able to see/hear critical parts of it? (Especially considering that, if I recall correctly, support for audio and video multimedia was one of the highly touted "features" of OOXML over OpenDocument.)

— Steven G. Johnson 00:51, 20 January 2007 (EST)

"Application-defined" defaults?

There are a number of elements which are not required, but if omitted lead to "application-defined" default behaviors. See

• docDefaults (2.7.4.1): Document Default Paragraph and Run Properties
• pPr (2.7.4.2): Paragraph Properties
• pPrDefault (2.7.4.3): Default Paragraph Properties
• rPr (2.7.4.4): Run Properties
• rPrDefault (2.7.4.5): Default Run Properties

— Steven G. Johnson 02:05, 20 January 2007 (EST)

Equation shape objects in drawings are not editable unless you are Microsoft?

Section 6.1.2.19 defines the "shape" element in VML, "the core object in VML". One of the attributes of this element, on page 4653 (PDF p. 5436), is "equationxml", defined as:

Specifies alternate XML markup which may be used to rehydrate an equation using the Office Open XML Math syntax. The actual format of the contents of this attribute are application-defined, but shall contain Office Open XML Math as well as any application-specific content.

My understanding that this attribute is intended to be used if you have an equation object in your drawing, and you want to edit the equation using the math editor — in that case, you need the original equation XML to access the mathematical structure. However, since the contents of this attribute are application-defined, in practice this is apparently possible only if you want to edit the object in the same program that created it. (Saying that it "shall contain" OOXML math doesn't seem like much help...shall contain how? After 327 bytes of application-specific content and gzipped?)

— Steven G. Johnson 03:04, 20 January 2007 (EST)

"Application-defined" binary blobs within shape objects?

Section 6.1.2.19 defines the "shape" element in VML, "the core object in VML". One of the attributes of this element, on page 4655 (PDF p. 5438), is "gfxdata", defined as:

Specifies a base-64 encoded package as deifined [sic] in Part 2 of this Standard that contains DrawingML content. The contents of this package are application-defined, but the contents of the package shall use the Parts defined by this Standard whenever possible. [Rationale: This attribute allows an application to use VML to represent graphical content while still persisting DrawingML for consuming applications that support DrawingML. For example, a diagram stored within this attribute would have the four parts defined for a DrawingML diagram, as well as any number of application-defined parts and relationships. end ationale]

An "application-defined" base64-encoded binary blob in the middle of your drawing?

— Steven G. Johnson 03:09, 20 January 2007 (EST)

"Application-defined" binary blobs for Microsoft Ink™ data?

Section 6.2.2.14, on page 4813 (PDF p. 5596) of the standard defines the "ink" element as:

This element specifies the presence of an ink object. An ink object is a VML object which allows applications to store data for ink annotations in an application-defined format.

The actual data for the "ink" object is stored as a base64-encoded binary blob in the "i" attribute.

This is obviously a thinly-veiled way to include the proprietary Microsoft Ink tablet-PC annotation content in OOXML, without documenting the format used. (According to MS documentation, Ink can be stored as either "fortified" GIF or ISF (possibly wrapped inside of another file format [1]), but the canonical format is apparently the Ink Serialized Format (ISF), an apparently undocumented "highly compressed binary representation of the ink data from a lone ink object." "Fortified" GIF files apparently contain ISF via metadata [2].)

(Just because it's "annotation" data does not mean it's superfluous. Microsoft promotes Ink for use in exchanging copy-editing information as part of Office files, for example. Nor is it clear whey they couldn't use a standard format like PNG for representing transparent bitmaps, or SVG if they want to represent stroke data; the small amount of additional metadata, such as original device coordinates, that ISF encodes could be documented and added as metadata in PNG or SVG. Not to mention the fact that base64-encoding it directly in the XML seems rather silly when it could just be stored as a separate file part.)

— Steven G. Johnson 03:16, 20 January 2007 (EST)

Bitmasks are not subject to endian issues when represented as numeric strings

Contrary to (apparently) popular misconception, the use of bitmasks does not inherently cause endian issues. Endian issues only arise in serialized binary formats, and not when numbers are represented by ASCII numerals in whatever base (as in OOXML). (I have a fair amount of experience in dealing with both binary file formats and bitmasks in portable software.)

Whenever a number is written as a string numeral, whether as a decimal number like "21" or as equivalent hexadecimal like "0x15" or as an equivalent binary string "00010101", there is no ambiguity: the digits are always arranged from most to least significant (in English and standards based on English, at least). It is only when this number is represented in a computer's memory by a sequence of bytes that the byte-sequence varies depending on endianness.

Similarly, bit operations in progamming languages are not subject to endian problems, because they are specified in terms of either ASCII strings or bit-shifts relative to the "logical" least-significant bit, regardless of the binary form of the compiled machine code. For example, if I want to set the 13th least-significant bit of an integer "x" in a C program, I would do something like: "x | 4096" or "x | 0x1000" or "x | (1 << 12)". If I subsequently print out the value of "x", using printf, as a decimal or hexadecimal number, I will get the same result on both big- and little-endian systems. I will only have a problem if I typecast &x to "char *" and print out the bytes one by one.

As another example, consider the "chmod" command in Unix, which allows you to specify the file permissions as a bitmask in octal. "chmod 0644", where "0644" is an octal numeral, sets the same file permissions on both big- and little-endian systems.

So, in short, while OOXML's use of bitmasks has numerous problems, portability between different-endian systems is not one of them.

— Steven G. Johnson 20:52, 21 January 2007 (EST)

I agree. Months ago when I first noticed the bitmasks I had a "gotcha" moment where I was sure it was endian-dependent. But further reflection convinced me that it was OK. The stronger criticism here is that bitmasks defy validation by XML Schema, don't work well with XML tools like XSLT, and are just plain silly in a XML format that is going to be zipped up in the end.

--Cicero 22:34, 21 January 2007 (EST)

ST_Panose defined twice

ST_Panose is defined in 2.18.72 (page 2569) and 5.1.12.37 (page 4502). Is that legal? Or is there some implicit namespacing I'm missing at this low level? I discovered this when dredging through all the hexBinary issues. --Trollsfire 16:13, 22 January 2007 (EST)

If having multiple definitions is a problem, then ST_TwipsMeasure is defined both in 2.18.105 (page 2619) and 7.1.3.16 (page 5884). The definitions seem compatible, but still.

--Trollsfire 19:36, 22 January 2007 (EST)

Multiple types used for RGB coding

In digging through all the hexBinary inconsistencies, I discovered that there are three different variable types used for storing RGB data:

• ST_HexColorRGB (2.18.45, page 2520) which, in my opinion, is the best named
• ST_UnsignedIntHex (3.18.86, page 3712) which is 4 octets and may be used for thing other than RGB color as well
• ST_HexBinary3 (5.1.12.28, page 4483) which is accurately named for what it is (a length 3 (3 octet) hexBinary variable) but not what it does

I reference this in the section about the hex inconsistencies, but should this be extracted from there and put elsewhere? A section about internal redundancies (multiple definitions for the same things), maybe? --Trollsfire 16:20, 22 January 2007 (EST)

cryptography and fields

The end of 2.5.1.28, p 1165, worries me quite a bit: not only is there the ability to use any encryption method desired, but any possible external module might be used to create it. algIdExtSource + algIdExt just screams "embrace and extend". On a related topic, 2.6 (p 1487) talks about fields, and "The act of carrying out a field's codes is referred to as a field update. As to how or when any field is updated is outside the scope of this Office Open XML Standard." 2.16.4.1 has a similar comment: "If no date-and-time-formatting-switch is present, a date or time result is formatted in an implementation-defined manner." --Dogcow 16:46, 22 January 2007 (EST)

Good finds! I've added your 2.16.4.1 example to the section "Relies on application-defined behaviors". We might consider adding your other two examples if the problems with them can be clearly explained. (For example, how might inconsistent field-updating cause interoperability problems? Is this just an user-interface issue?) — Steven G. Johnson 19:26, 22 January 2007 (EST)

Paper Sizes

Section 3.3.1.61 page 2770 "pageSetup" (Page Setup Settings) and 3.3.1.62 page 2774 "pageSetup" (Chart Sheet Page Setup) have an Attribute entitled 'paperSize' which is enumerated to 68 fixed paper types. This is contradictory to the naming convention of paper sizes as defined by ISO 216 (A,B,C sizes) used internationally and ANSI Y14.1 used in the USA.

• Wikipedia: Paper Size

I agree that this is a relatively small issue, but it does show Ecma 376's restriction on the choice of paper sizes and its insistence to use internal lookup tables contrary to ISO names and also defeats the purpose of readable XML. -- Yoonkit 23:02, 22 January 2007 (EST)

I agree also, and I re-added this section in the following form:

Nonstandard, inflexible paper-size naming

Sections 3.3.1.61 (page 2770) and 3.3.1.62 (page 2774), both of which involver printer settings, define a "paperSize" attribute whose value is an integer representing one of 68 fixed paper sizes. These paper-size codes are apparently based on corresponding paper-size registry codes in Microsoft Windows, rather than using the standard paper-size names as defined in ISO 216, ANSI Y14.1, and similar standards. In contrast, ISO 26300 employs a much more flexible scheme: it simply describes the paper size by recording the physical width and height of the page, leaving the assignment of symbolic paper-size names to the user interface.

As you might have guessed, these inflexible 68 numeric codes are a direct dump of a Windows-registry data structure. — Steven G. Johnson 01:13, 23 January 2007 (EST)

Thanks very much for including this in. -- Yoonkit 01:54, 23 January 2007 (EST)

Uses a Microsoft-specific namespace

This is whats currently written.. Section 6.2.3.23 page 5197 Attribute "href" (Hyperlink Target) uses a Namespace "urn:schemas.microsoft.com:office:office".

An Ecma standard must not reference company-specific namespaces. This should be replaced by an Ecma namespace.

--

Ive done more checking, and the VML Reference Material, pg 5126 states:

"To maintain backward compatibility, all VML namespaces defined in this specification maintain the legacy namespace structure already used by millions of documents.

[Note: The VML format is a legacy format originally introduced with Office 2000 and is included and fully defined in this Standard for backwards compatibility reasons. The DrawingML format is a newer and richer format created with the goal of eventually replacing any uses of VML in the Office Open XML formats.

VML should be considered a deprecated format included in Office Open XML for legacy reasons only and new applications that need a file format for drawings are strongly encouraged to use preferentially DrawingML."

So it explains why the namespace is there, but it does not explain why a deprecated format is being included in this "modern" spec. How should we rephrase this concern?

Yoonkit 21:27, 22 January 2007 (EST)

I've taken a stab at rephrasing it. See the document. — Steven G. Johnson 21:39, 22 January 2007 (EST)

OK, that reads OK, Thanks! -- Yoonkit 22:55, 22 January 2007 (EST)

A string is used to define deprecated VML in DrawingML

section 6.5.22 (p. 5743) "textdata"

This element specifies optional supplementary text information associated with a legacy VML shape that is a node in a VML diagram when it cannot otherwise be stored within the DrawingML framework.

[Note: An application could use this to preserve a specific diagram format for backward compatibility, but it is strongly recommended to upgrade all VML shapes to DrawingML shapes. end note]

Is this the "billions" of backward compatibility support? store it as a "textdata"?

Yoonkit 21:36, 22 January 2007 (EST)

Ecma 376 contradicts SVG colour names

This got dropped yesterday:

--

SVG color values

Ecma 376 section 2.18.46 page 2521, contradicts the SVG Color Keyword Names hexadecimal RGB values for given color names.

Colour Name SVG Ecma 376 Dark blue 00008B 000080 Dark cyan 008B8B 008080 Dark gray A9A9A9 808080 Dark green 006400 008000 Dark red 8B0000 800000 Light gray D3D3D3 C0C0C0

Compatibility Note

There is no need for redefining color names to achieve compatibility with existing Microsoft Office documents. Microsoft is free to use whatever color names it wishes on its office application and store the hexadecimal color value in the file.

--

I think its quite important that we show how colours are changed in the spec, and will cause problems. As demonstrated by the colours, they are quite different, e.g. DarkGray and DarkGreen.

Its a direct contradiction with completely different RGB values. -- Yoonkit 22:58, 22 January 2007 (EST)

I agree. This section was apparently deleted without explanation by User:Dcarrera, who I've noticed has been making unexplained and repeated deletions in numerous sections. Not from malice, I think — I suspect he's doing it in the name of brevity and focusing on the most important points. He/she wrote, as a hidden comment in the article:

The OBJECTIVE of this document is NOT to have an exhaustive list of everything weird or unusual in the Ecma spec. The OBJECTIVE is to make a strong argument. A strong argument is not made stronger by adding weak points. Adding weak points makes the argument WEAKER because it looks like you are hair-splitting and makes the good arguments harder to find.

My feeling is that, while the most important points are surely the duplication of OpenDocument, SVG, and other existing XML standards, these little inconsistencies and oddities go a long way in demonstrating the haste and lack of care in the Ecma process. The thing with little inconsistencies and oddities, however, is that because they are each minor things individually, it is really by force of numbers that they make their case. Furthermore, this page (as far as I can tell) is mainly intended as a resource for those who wish to object to Ecma 376, since we cannot submit objections directly, and therefore should err on the side of inclusiveness. I'll restore the section. — Steven G. Johnson 00:09, 23 January 2007 (EST)

Ive found that Section 5.1.12.48 (p. 4531) "ST_PresetColorVal" (Preset Color Value) has excellent correlation with SVG colors. But of course it misses the opportunity for following well defined standards but continues to subvert it with a different name "darkGray" becomes "dkGray" -- Yoonkit 01:29, 23 January 2007 (EST)

Ive blogged this at: SVG Colour Contradiction --- Yoonkit 14:24, 26 January 2007 (EST)

Legacy Information

there's more to be added here, another "minor" concern, but may be significant if we can catalogue all the "legacy" tags which can be represented or duplicated with similar functionality in the modern spec -- Yoonkit 01:13, 23 January 2007 (EST)

Preset Color

Section 5.8.2.6 (p. 638) "prstClr" (Preset Colour)

"This is a legacy definition of colors which is no longer currently used. A preset 5 color is a choice from among several presets provided in older versions of Office."

why is this in a modern spec? why not use SVG colours? or convert to new spec colours as in 5.1.12.48 (p. 4531)?

"Application-defined" and undefined "legacy" merge document formats?

In section 2.18.63, ST_MailMergeSourceType (Mail Merge ODSO Data Source Types), which is described as "purely a suggestion" about the source type, many of the possible enumeration values are undefined or poorly defined. It's not clear to me what the practical impact of this "suggestion" is, so I don't know how serious an omission this might be.

Two of the possible enumeration values are "document1" and "document2" on p. 2549 of the PDF, defined as:

Specifies that a given merged WordprocessingML document has been connected to another document format supported by the producing application. The format of this document is application-defined and outside the scope of this Office Open XML Standard.

Another of the possible enumeration value is "legacy", defined as:

Specifies that a given merged WordprocessingML document has been connected to a legacy document format supported by the producing application. The format of this legacy document is application-defined and outside the scope of this Office Open XML Standard.

More of OOXML's touted backwards-compatibility at work?

And then, in case there weren't enough application-defined mail-merge source types, another enumeration value is "native", defined as:

Specifies that a given merged WordprocessingML document has been connected to another document format native to the producing application. The format of this document is application-defined and outside the scope of this Office Open XML Standard.

Another format is "text", defined as:

Specifies that a given merged WordprocessingML document has been connected to a text file.

7-bit ASCII? Unicode? It doesn't say.

— Steven G. Johnson 02:38, 20 January 2007 (EST)

Another undefined "legacy" feature: the DigSig element

7.2.2.6 defines the DigSig element (page 5105):

This element contains the signature of a digitally signed document. [Note: This property is a mechanism used by legacy documents to store the digital signature of its binary representation, and should be considered deprecated in favor of the well-defined mechanism defined in Part 2. Any use of this property should be for legacy compatibility only, and is application-defined. end note]

(Note that it is "application-defined", and no other information is given.)

— Steven G. Johnson 03:22, 20 January 2007 (EST)

Microsoft Office names

Section 6.2.2 (p. 735) "Placement" "MSO-Position-Horizontal"

"Specifies relative horizontal position data for objects in WordprocessingML."

What does 'MSO' represent? Micro-Soft Office? horrors.

6.1.2.2 (p. 5145) "style" (Shape Styling Properties) is based on CSS2 and subverts it.

Specifies the CSS2 styling properties of the shape. This uses the syntax described in the "Visual formatting model" of the Cascading Style Sheets, Level 2 specification, a Recommendation of the World Wide Web Consortium available here: http://www.w3.org/TR/REC-CSS2. Full descriptions of each property are not repeated here, but the VML treatment of each property is defined. Allowed properties include:

• mso-position-horizontal
• mso-position-horizontal-relative
• mso-position-vertical

...

• mso-wrap-style
• mso-direction-alt

Admittedly VML will be deprecated, but why is this here?

This is re-declared many times (lost count, but more than 8 times!) till p.5640 ...

Yoonkit 01:40, 23 January 2007 (EST)

VML and DrawingML

Section 6.1 page 5126 "VML" states:

"VML is a language for defining graphical objects in cases where DrawingML does not apply, such as text boxes and shapes in WordprocessingML documents and comments and controls in SpreadsheetML documents. This namespace provides the base elements and attributes for defining shape primitives. Other VML namespaces define elements that layer on information beyond the baseline graphical definition. To maintain backward compatibility, all VML namespaces defined in this specification maintain the legacy namespace structure already used by millions of documents."

• Does this mean that DrawingML (5 page 3994) is inadequate and not complete? How can 2000+ pages NOT supercede the features of VML?
• VML is obviously provides functionality to WordprocessingML and SpreadsheetML, so it wont be going away anytime soon.
• VML (8.6.2 page 25) is mentionned as "should be considered a deprecated format", is this very important to require everybody to implement this format if it's already deprecated. VML specification is 617 pages (from 5126 to 5743).

OOXML defines two *different* hashing algorithms

Ecma 376 section 2.15.1.28 (page 1941) does not follow the advice of any of these organizations. Instead, it defines a new hashing algorithm that has not undergone scrutiny by the cryptographic community. Section 3.3.1.69 page 2786 "protectedRange" has yet another implementation called 'GetPasswordHash'

I don't think this is correct. Sections 2.15.1.28 and 3.3.1.69 define two different insecure hash algorithms, not just different "implementations." (For example, 2.15.1.28 defines an "encryption matrix" of words to XOR with the key, but 3.3.1.69 uses no such matrix.)

I've fixed this twice already, and both times my changes have been reverted without explanation, most recently in an enormous edit by User:Marbux. This kind of behavior seems to be common on this page, and it's getting annoying (see below).

And now the page is protected. WTF?

— Steven G. Johnson 12:22, 23 January 2007 (EST)

Does nobody know wikiquette?

Just today, User:Marbux deleted several sections of the document, including several that had been discussed above, and reverted numerous other changes in the document. All in a single edit with no edit comment.

I'm beginning to hate editing this wiki, because the same things are happening repeatedly.

A few clues:

• Use edit comments to explain what you are doing for non-trivial edits.

• Edit a wiki page by making changes to the relevant sections, not by editing the whole document at once and blowing away everyone else's changes in the meantime.

• If you want to delete large sections of other people's edits, it's polite to give some explanation on the Talk page, and preferably wait for comment first.

• Don't revert the same text repeatedly without explanation.

— Steven G. Johnson 12:22, 23 January 2007 (EST)

The whole ISO 639 issue is not correct

Forget this whole issue about ST_LangCode simple type that use hex values. All references to languages in the Word document format use the ST_Lang simple type, which is described in clause 2.18.51, and which does allow for use of ISO 639.

See also Wouter van der Vlugt blog

I suggest the issue is removed from the different pages. HAl 08:35, 30 January 2007 (EST)

It is true that ST_Lang is either and ISO 639 language code or an ST_LangCode. However, that means that every application which can read these documents must implement both forms (and convert these forms into the application's appropriate internal format). If ST_LangCode does not offer any functionality that can not be noted with ISO 639 codes (I have not checked to see if there are any languages which are listed in ST_LangCode but are not in ISO 639, but I do know there are languages in ST_LangCode which are in ISO 639), why does it even need to be there? You are correct that it isn't proper to say that ISO 639 isn't supported; more properly, the standard requires handling ISO 639 and a second, hardcoded, redundant, and so for unjustified way of supporting languages. This burden is borne by all implementers for no real benefit. (Actually, I believe the benefit is solely to Microsoft since these codes correspond to the codings in Windows; standards should not confer benefits to one party with the costs borne by all other parties. However, this aside need not even be true for two language designations to be a bad idea in a standard.) --Trollsfire 13:32, 6 February 2007 (EST)

I am glad that someone finally agrees this objection is not valid. I can see what you mean with supporting two languages but actually the ooxml standard has no requirement in what you do or do not support. So reuirement is not exaclty correct I guess any implementation wanting to be fully compatible with MS Office would require the hardcoded table for reading the file but those applications will do so anyways and probably already have this tables. I would think that most application will just use a hardcoded ISO 639 translation table that has an extra column with this numbering.

However most applications will only support the ISO language code in writing and applications that write Office files are much much more important than reading as the office formats are now in reach of normal .NET, java or other applications that can easily create direct office document output. It would be good if MS office 2007 would also always use at least the ISO coding but I haven't got any files created with Office 2007 to see if it does. HAl 14:38, 6 February 2007 (EST)

On some things, I think we are coming to an agreement. It is wrong to say that OOXML does not support ISO 639. However, there are still areas that we disagree on, or at least disagree on the importance of. It is true that there is not a requirement to implement the entire standard, but saying that is somewhat disingenuous. If you are only producing OOXML, then you only need to support a sufficient subset of the standard to be able to represent that which you are producing. You need only choose one way of doing things when there are multiple options (such are here, only using one form of language designation). However, if you are consuming OOXML, you must be able to handle all the possibilities (at least for the functionality you implement). Any consumer of OOXML (any application that reads OOXML, not just writes it) must be able to understand all possible ways that the language may be encoded.

You assume that the number of applications which will create OOXML will vastly outnumber those that can read OOXML. That might be true; I even assume it is true with .doc files now. Likely, many more programs can create output that Word can read than can read .doc files (maybe around half a dozen, not counting different versions of Word separately?). One of the purposes of having a standard file format, though, is that it makes it considerably easier for multiple applications to read, transform, and write the data in those files. That is, the standard should not make reading significantly more difficult than writing by having alternate ways of doing things which do not add functionality. That is the problem I have with the whole ST_LangCode thing: it adds complexity for all consumers of OOXML without adding any functionality or capability. As you have stated, it could be done with the ISO 639 support that is in OOXML, so it really doesn't need to be there from a capability prospective.

As a bit of an aside, I did find a place in the spec which uses ST_LangCode by itself (rather than ST_Lang): on page 2323 of the PDF, a switch (z) for the INDEX field definition takes only an ST_LangCode. I don't consider this major, in that the spec could be modified for that to take an ST_Lang instead, but it is an example of small problems in the spec that should be fixed. (Note that changing it would break no producers of OOXML, but could break consumers of OOXML which were not expecting the ISO 639 part of a ST_Lang there. This is an example of the differences producers and consumers of a format face.)

--Trollsfire 14:31, 8 February 2007 (EST)

OOXML does use standard dates.

In most of the spec OOXML conforms to the standard W3C XML schema validation. The standard XML does not use ISO 8601 but a subset of ISO 8601. The ISO 8601 standard is extremly extensive and put a lot of extra implementation effort to fully implement which is why w3c implemnets the subset which is reused by OOXML.

As for the issues raised about the 1900 and 1904 date formats. The 1900 and 1904 date format are for use in spreadsheet cells only. It would be extremely difficult to implement ISO 8601 correctly in spreadsheets. For instance when two date are subtracted in ISO that leaves a 'period' it would be something that is very weird implementing into a spreadsheet.

Example Cel a contains 20070214T131031

Cel b contains 20070214T131030

Cel c contains 20070214T131030/20070214T131031

These are all correct ISO 8601 where in cell c there is effectivly a 1 second period that corresponds with the difference between cell a and cell b.

In an internal spreadsheet formula format that would represent as: Cel a 39127,548969907400

Cel b 39127,548958333300

Cel c 0,000011574113

This is an example of the internal Excel 1900 date format where in cell c also is a 1 second period that corresponds with the difference in cell a and cell b. However it is virtually impossible to go from ISO to internal format and then convert back to ISO without data loss.

To prevent this an application should therefore also use the ISO format as an internal format and convert the format for every individual calculation with the format which would be extremly slow and isn't used by any spreadsheet. HAl 09:18, 30 January 2007 (EST)

---

But the point is not that EOOXML uses a start date to calculate days. The point is it use two start dates, 1900 and 1904, and that it calculates the wrong number of days when using 1900 as a start. Forcing all other applications to miscalculate leap years is rather awkward. Furthermore, EOOXML does not allow dates BEFORE 1900. Which would make the use of EOOXML spreadsheets for historical research "difficult". For instance, you cannot use EOOXML spreadsheets to study Washington's book-keeping, or the costs of the war of independence. --Winter 03:10, 2 February 2007 (EST)

The ISO 8601 standard only uses gregorian time which is only used for valid dates after 1582 as before that time historians use Julian time. So use of spreadsheet date fields is limited for historians whatever standard you use. Definitly the ISOO standard has more possibilities but a big big questionsmark can be put over it's usefullness in spreadsheets. The date1900 is much simpler for shreadsheetuse and serves definitly a different requirement (namely processing) then the ISO format. Therefore is is not a contradiction as such. The leap year issue I do find a valid issue as well but it is also a very minor issue. In implementing it is just adding 1 extra if statement.

Date1904 seem for use in converters and legacy Apple applications only. That is a valid item for legacy implemention which is actually an important goal of the standard. So that is no issue but a normal part of the spec but one that almost no implementations will need to support. HAl 04:34, 2 February 2007 (EST)

HAl, I dont understand; I need your help to explain this. Why can't the application write to file using ISO 8601 e.g '20070214T131031', and upon loading, convert it to whatever internal number the application implements? e.g. If the internal value was '39127.548969907400' it will keep it as that until the need to save to file. Would that solve the 'period' and 'performance' problems? Is it such a chore to parse the ISO 8601 once on the read process? If the application has to load up Lotus1-2-3 files then it just loads up '39127.548969907400' as '39127.548969907400'. No big deal. Instead MSOOXML is forcing the new writes to remain '39127.548969907400' thus propagating this bug forever. Yoonkit 06:29, 2 February 2007 (EST)

The leap year bug is a seperate issue from the use of which format. The leap year bug is to be able to maintain 100% valitity with legacy spreadsheets. Because you cannot realiably detect which dates are affected or not you cannot realiably convert dates in old spreadsheets to get rid of the bug. However I think a better solution would have been possible. HAl 07:49, 2 February 2007 (EST)

The issue here is: why not keep the MSOOXML format "correct" in that it stores date/times as humanly readable text without the burden of legacy issues. That way the "leap year bug" doesnt become an issue at all. Only when reading OLD .XLS files, the "import file filter" will have to read the internal format number and interprete it as such, as defined by the current spec. Yoonkit 23:21, 8 February 2007 (EST)

The format use issue. You claim that you can convert ISO dates into a processing format and back. This hoever is not per se correct. Because ODF for example specified periods of time as a valid datatype it is incredibly hard to convert them 100% reliable to a processing dataformat and back. To be able to do reliable conversions it requires that the internal format is exactly as complex as the ISO format. That would take away the advantage of using an simple internal format for calculations. HAl 07:49, 2 February 2007 (EST)

Is this now an ODF issue? Back to topic: I "recommend" that MSOOXML convert from a readable datetime format to its internal format (for whatever reasons) and then write it out as a readable datetime. How difficult is that suggestion to implement? Yoonkit 23:21, 8 February 2007 (EST)

No, this is not an ODF issue of course. It is a choice in OOXML. Allthough I would not object to supporting limited iso dates in sprreadsheet cell I can see why another choice is made. To suggest that the dates should be humanly readable however is nonsensical as the format is not ment to be read by human at all. suggestions about readability of data in an OOXML file I find laughable. Howevers a reason for using an iso format in this case would be that it has better daterange and supports timezones. It would not be bad if OOXML were to add additional support for such dates in spreadsheet cells. That is what I would recommend. HAl 07:41, 9 February 2007 (EST)

Also such conversion if it were possible could take a long time if the spreadsheets have lots of datefields. (I currenctly have a few with almost a million dates but that is because I was limited to only 65k rows before so they will soon contain about 4,5 million dates or more. Because date1900 is a date format made for easy processing in spreradsheets it certainly does not contradicts ISO 8601 as that certainly is NOT created as processing format. HAl 07:49, 2 February 2007 (EST)

You still have to convert between the chars you read from file to a decimal value in memory. And this is probably the bottleneck. To do an in-memory parsing from a proper ISO datetime string to a datetime datatype shouldnt be too much of a performance hit. The majority (>90%) of all spreadsheets do not share your requirements. I would suggest that you dont use a spreadsheet to handle those gazillion datetimes but use a proper better designed custom-app solution. So the tradeoff between performance for readability and future proofing of gazillion documents is really not justified. Yoonkit 23:21, 8 February 2007 (EST)

The suggestion that the char conversion is important is incorrect. When using a iso format the file data has to be converting to a memory string before it can be parsed and converted to an internaldate and the size of the ISO string is generally longer than a numeric date so that only takes extra time. HAl 07:41, 9 February 2007 (EST)

Licensing

The information provided on licensing does not list the analysis by Baker and Mackenzie that was done for Microsoft. http://www.bakernet.com/BakerNet/Resources/Publications/Recent+Publications/OpenXML.htm

As a legal analysis provided by a reputable legal firm contracted by Microsoft it would seem to hold more legal status than any analysis done by Groklaw. Microsoft can't really go against the legal analysis that are provided and published by the legal advisors on behalf of Microsoft for informing their relations, customers and governments.

The fact that this legal analysis is not mentioned by Groklaw seems a serious flaw in any legal reasoning about the licensing of the Office Open XML format.

I wonder why Groklaw does not use that official analysis as an important source of interpreting the CNS but in stead tries to create an alternate analysis ???? HAl 10:37, 31 January 2007 (EST)

---

You are right it should have been mentioned. I would really like to see that, because I cannot find any point where it is actually stated that MS grants anyone rights to use their patented technology to implement EOOXML in full. The closest part to stating something about this in the analysis I found was:

There are three qualifications detailed in the Microsoft CNS, which are also present in Sun’s Covenant and reflect standard industry practice.The first is designed to protect Microsoft from the actions of others. It states that the covenant will not apply where a person asserts or threatens to assert rights against Microsoft.The second qualification concerns the scope of Microsoft patents: it is designed to put users on notice that a conforming implementation of the Schema may not include a patent claimed by Microsoft or, if the conforming implementation does include such a patent, that the patent may not be enforceable.The third qualification addresses the intellectual property rights of others that any conforming implementation of the Schema may contain. Microsoft is not in a position to protect users from any such third party infringement.The second and third qualifications are designed to protect Microsoft from any liability arising from the implementation of the Schema. As such, neither impact on the ‘safe harbour’ users are given under the CNS from any Microsoft enforcement action.

IANAL. Now does MS grants me the right to implement EOOXML in full or not?

Wierd you cite from the analysis a part that does not focus on rights but on explaining the restriction of the CNS that are simular to the restricions that are posed by Sun's CNS on OpenDocument.

When looking at the analysis looking for rights I would focus on very usefull parts like this: The CNS is designed to simplify the implementation of the Schema by users. As noted above, this is achieved by removing any usage limitations on those implementing the Schema. In the course of implementing the Schema, it is likely, if not inevitable, that the Schema will be incorporated into products that are designed to interoperate with Microsoft’s Office 2007, as either complementary or competitive applications.The CNS does not affect users’ rights to create their own applications using the Schema specifications. For example, there are no restrictions in the CNS that would prohibit third parties from incorporating the standard into applications they create and distribute in source code form, or for other hardware or operating-system platforms.

Do you see any restricting in implementing from that ??? Somehow it seems this kind of information isn't allowed on the Grokdoc as it might actually seem that it contradicts most of their claims mayby ????

You should probalby also note that Microsoft cannot grant rights that are in the hands of standards organisation Ecma international which is the author and publisher of the final standard document. HAl 05:01, 2 February 2007 (EST)

The ISO/IEC 8632 (Computer Graphics Metafile) issue. More FUD

The objections about the OOXML spec contradicting ISO/IEC are really ridiculous. I know this FUD came from OASIS attorney Andy Upgrove but did anyone ever read the OOXML spec on that subject.

I'll cite the blog by Wouter van Vugt as he seems to have worded it best:

Similarly, 6.2.3.17 Embedded Object Alternate Image Requests Types (page 5679) and section 6.4.3.1 Clipboard Format Types (page 5738) refer back to Windows Metafiles or Enhanced Metafiles

Either someone misread the OOX specs here, or they are just trying to throw in another ‘contradiction’ in there to try and foil the evil empire. OpenOffice uses Metafiles for embedded objects, so I doubt anyone out there would really think it’s a crime to do so. The Open XML spec does not contain any requirement on EMF or WMF. The section people are talking about (6.2.3.17) can use any format. The allowed values for clipboard format types are "Bitmap", "Pict", "PictOld", "PictPrint", and "PictScreen". The spec then gives you some potential formats based on those values, saying that "Pict" and "PictOld" could be mapped to the WMF and EMF formats. Though the spec could be more informative of this though.

HAl 05:19, 2 February 2007 (EST)

Poor semantics in Licensing discussion

From the objections: However, glossing over that problem by assuming arguendo that some rights were granted nonetheless, the existence and scope of those rights can only be determined by examining the specification itself to determine the meaning of conform and its variants. But those are rights identified in another document, the specification, not "in this [covenant/promise]." That is fatal to any attempt to use the Ecma 376 specification as a source of rights granted because the reader is forbidden from looking to another document as a source of implementer's rights not expressly stated in the IP documents.

This text is ment to state that the specs of OOXML cannot be used to define conformance (which it actually does define in the part 1 funcdamentals).

But actually the spec CAN be used very well to show what is conformance. The cited clause from the objections page states that no 'rights' are granted that are not in the promise/covenant. however conformance is not a 'right' as such and the fact that it is not in the text of the OSP or CNS therefore does not matter.

It would be actually be kind of hard hard for Micrsoft to define conformance on a spec that is controlled by Ecma. Only Ecma can define conformance and a such they have done that in the spec itself. That conformance paragraphs make it clear that no full implementation is required to conform to the Ecma specs. So as Ecma has defined conformance in the spec, Microsoft can reference that definition in their CNS/OSP without any trouble. HAl 11:43, 2 February 2007 (EST)

Patent claim

The groklaw objections state that:

"software may employ methods and concepts described in a patent's claims, but the patent claims are not the methods and concepts described therein"

However this is not correct at all. In software patents the patent claim in general is the method or a system to implement the invention.

So in granting rights to patent claim to software you actually grant rights to methods and systems that implement an invention. The objection state that you cannot grants patent rights to implement things but that is therefore not correct. HAl 06:52, 3 February 2007 (EST)

Objections against examples ???

The following is listed as an objhection:" Mismatched detailed description The text that describes USERINITIALS, section 2.16.5.77 (p. 2353–2354), instead discusses USERNAME.

However this is a very minor error not in the description but in an example text. So it has no real effect on the standard whatsoever. Does anyone really consider this a serious objection that matters in ISO standardization ? what's next ? Are we going to list spelling error's and typo's to as objections ?

I just looked at the ODF specs. They have revision lists for version 1.0 revised edition and version 1.1 full with minor error like this. Some very minor issues do not grant objective reasons to object against the standardization as is suggested here by Grokdoc/Groklaw. HAl 07:46, 6 February 2007 (EST)

No one is claiming that that example, by itself, is sufficient reason to reject Ecma 376. However, the sheer number of such minor problems, throughout Ecma 376, are evidence that the standard was prepared hastily and is immature. This is clearly stated in the introduction to that section (see also below); stop playing rhetorical games. The major objections, of course, remain the fact that Ecma 376 is massively duplicative of other standards, especially ODF (rather than extending ODF as needed), and that it relies on unspecified information (if you want to fully interoperate). — Steven G. Johnson 12:11, 8 February 2007 (EST)

I disagree on several things. Firstly Grokdoc/Groklaw do not present it as a fault in an example suggesting it is worse then it is. Secondly The sheer number of flaw is not shocking. It falls within reason for a large complex spec. Thirdly OOXML has other goals then ODF and the spec is suited to those goals. That in itself a major difference between the specs. There is overlap but overlap is not nescesarily contradiction. There is no reason that both specs can't exist. Fourthly I do not agree that the spec relies on unspecified information. Only depreciated features from older MS Office files are not in the spec and clearly this spec only supports identifying those items and does not support those features any longer and therefore even full implemention of this spec does not require supporting any of those features. HAl 18:11, 8 February 2007 (EST)

A TWIPpy objection ???

A TWIP (twentieth of a point) is mayby not a standard ISO size measument but it is a derived measument based on PostScript points. As postscript, which is globally used as a printer format , uses points measuments I cannnot see that a small item of points measurement in a closely related to postscript Office format would be a problem which warrant objections for ISO standardization. Is this realy a serious listing of things that warrent objections against the standard or just a colletion of nitpicking items to create an atmosphere of FUD around the OOXML standardization. HAl 08:06, 6 February 2007 (EST)

You're taking it out of context. See the introduction to that section:

Even in the limited time available for public review of more than 6,000 pages, a large number of inconsistencies and flaws have become apparent in the Emca 376 specification, in addition to the major omissions and disregard for existing standards described elsewhere in this document. Although any one of these flaws, taken individually, is easily corrected, together they demonstrate the undue haste and lack of care that went into the rapid drafting of this proposed standard.

No one is pretending that any of the flaws described in that section, taken individually, are reasons to reject Ecma 376, and indeed that whole section is presented as merely icing on the cake. By pretending otherwise, you are playing rhetorical games. (And of course, it's perfectly possible to make up new units; there's no mathematical problem with measuring distance in twips, EMUs, furlongs, or frobnicks. But it's rather careless in a proposed ISO standard, absent a good justification.) — Steven G. Johnson 12:15, 8 February 2007 (EST)

Bitmasks cause significant validation problems

I would like to see the reasoning behind this claim. Schematron can definitely validate bitmasks, either as binary number strings or HEX numbers; Following is some code as a rough example

  <rule context="x">
    <let name="i" select="." />
    <let name="bit1" select=" i - (floor(i / 2) * 2) " />
    <let name="bit2" select=" floor(i/2) - floor(i/4)*2 " />
    <let name="bit3" select=" floor(i/4) - floor(i/8)*2 " />
    <let name="bit4" select=" floor(i/8) - floor(i/16)*2 " />
    <let name="bit5" select=" floor(i/16) - floor(i/32)*2 " />
    <let name="bit6" select=" floor(i/32) - floor(i/64)*2 " />
    <let name="bit7" select=" floor(i/64) - floor(i/128)*2 " />
    <let name="bit8" select=" floor(i/128)" />

    <assert test=" $bit1 = 1"> The first bit should be 1</assert>
    <assert test=" $bit1 + $bit2 + $bit3 + $bit4 &lt;= 1 ">Only one of the first four bits can be 1</assert>

   </rule>

Furthermore, W3C XML Schemas can validate bitmasks, for example using regular expressions or enumerations or unions or numeric ranges. There may be a few constraints it cannot express compared to ISO Schematron, but that is typical for many kinds of schemas. Indeed, it is the fundamental concept in IS8879 SGML that the "Document Type Declarations" cannot capture all of the 'document type definition".Rick Jelliffe 18:40, 7 February 2007 (EST)

The above may well be just about doable. However, it will defy any attempts to validate and manipulate it directly through common XML tools without telling them what these masks mean and how to get at the actual data. What it does not answer is the question of 'why?' Why is this the case, and why is it necessary? OOXML is presumably a XML based format, and as such, should be parseable on that basis. It should be possible to parse XML elements and readily turn them into something meaningful. Additionally, it doesn't answer the extensibility issues of fixed length bitmasks. If someone is drawing a quick and dirty schema, for use internally in an organisation say, then this may be acceptable. However, for a proposed international standard where meaningful data needs to be extracted, it is more than questionable. Additionally, in trying to process bitmasks we potentially run into some platform specific issues that are never nice, when trying to work out byte ordering for example. XML seeks to be platform independent, as well as application independent, and seeks to leave these issues behind, as should any proposed international standard. segedunum 01:41, 9 March 2007 (BST)

The above *is* a schema: it gives an example of how you can validate bitfields. You can do the same with XSLT and with any tool that has even basic maths or string processing. In what way will it "all attempts" be "defied"? Rick Jelliffe 09:17, 10 March 2007 (EST)

On the issue of extensibility, a bitfield that is a collection of boolean values is no less extensible than if you had used separate attributes: in both cases you get extensibility by adding attributes. In any case, bitfields are rare, I think only two kinds of uses. They are the kind of thing that would get picked up in a general review or fixed by maintenance, in the normal case, and are not showstoppersRick Jelliffe 09:24, 10 March 2007 (EST)

On the issue of everything being marked up using XML, there is no such blanket rule. Embedded notations are common: dates, XPath, URIs, RGB. The point is whether the particular bitfields are justifiable, not that they exist at all.Rick Jelliffe 09:24, 10 March 2007 (EST)

On the issue of byte ordering, the order of the digits comes from the natural order of the text. I don't understand the point: are you saying that numbers in general are so prone to error that programmers should not use them? I wouldn't think so.

Non XML formatting codes

The names 'b', 'i' as bold and italic are HTML element names. They are hardly unfamiliar or uncommon or ambiguous. (Indeed, if my memory serves me, they are also used in a sample DTD by an ISO Technical Report (TR) from (now) SC34 on Techniques for Using SGML.) If CSS is allowed as standard for your purposes, why is HTML not?Rick Jelliffe 18:48, 7 February 2007 (EST)

XML does not define any element names. So it is incorrect to claim that any element name that is well-formed is "contrary" too XML.Rick Jelliffe 18:48, 7 February 2007 (EST)

Did you actually look at that page in the ECMA 376 spec? It is not using "b" and "i" as XML element names similar to HTML. It is using "\b" and "\i" at the end of a line to make the preceding line bold and italic, respectively. I agree that the Grokdoc explanation of this is confusingly worded, however. — Steven G. Johnson 12:03, 8 February 2007 (EST)

Yes I have looked at the page. The Grokdoc objection is not confusingly worded, it just makes a different point to yours, but they are quibbles. Using inline microformats to specify smart strings (such as the formatting and composition of index entries, as in this example) is a really common, basic technique with a long history (think OmniMark, Perl parameters, etc): it simply is not remotely novel or strange, nor is it a bad technical choice.

On your point of \b being used both as the start and end tag, I agree it looks strange to people accustomed to end-tags with different delimiters, but these are not used with any kind deep levels of nesting, so the risks of confusion are minimal. IS 8879 SGML deliberately chose to have different end-tag open delimiters than was used for the start-tag open delimiters, but it also allows a mechanism (short refs) where you could, say, alias "|" to mean "<b>" and then when inside the b element alias "|" to mean "</b>": this was indeed commonly used for small inline markup, because the advantage of small delimiters that didn't disrupt the typing line and which were efficient to type was greater than the risk of confusion from reused delimiters. Rick Jelliffe 21:56, 2 March 2007 (EST)

Submission form for objections to Standards Australia, due 21 August

The format for 'comments and observations' on Standards Australia's is in the form of a table, with the following column headings:

• Member Body
  • This will be "AU" for all Standards Australia comments
• Clause No./ Subclause No./ Annex (e.g. 3.1)
• Paragraph/Figure/Table/Note (e.g. Table 1) (optional)
• Type of comment
  • ge = general
  • te = technical
  • ed = editorial
• Comment (justification for change)
• Proposed change (what can we do to address the concern) (optional)
• Observations on each comment submitted

I'd like to coordinate the response with any interested contributors. The body of work is:

• Convert all outstanding objections into this format
• Find names of all contributors willing to attach their names to the submission

--Chiefpad 21:35, 13 August 2007 (EDT)

I've completed a first draft. If nobody has anything useful to add, I'm sending it to Standards Australia as a synopsis of all Ecma 376 issues that can be traced back to specific locations in the document.

--Chiefpad 09:31, 18 August 2007 (EDT)

Does Office 2007 use (E)OOXML

Hello

I have seen statements such as in http://www.noooxml.org stating that

There is no provable implementation of the OOXML specification:
Microsoft Office 2007 produces a special version of OOXML,
not a file format which complies with the OOXML specification;

Without any reference. On the other hand the wikipedia article about OOXML states, without reference the opposite. Could somebody please clarify this issue? Thanks Oub 10:04, 30 January 2008 (EST):