MSOOXML's disregard for existing standards.

There was a comment on my earlier concern on “MSOOXML contradicts W3C SVG Colour definitions” In it orcmid reiterates some facts which I have already mentioned but with a different view on things:

“The Windows color choices that you exhibit are selected from the *standard* color map that is defined for HTML/XHTML.

The idea is to make sure there is accurate rendering on a wide range of displays. The standard color map does not use color levels 64, 8B, A9, or D3 (although 00 is a universal winner for "darkest").

It would appear that SVG conflicts with another older and far more widely-used W3C standard. Fancy that.”

The colour choices defined in the Ecma 376 specification is not at all based on widely used W3C standards. It is based on something far older, which is a vendor defined Microsoft Windows color map. It should be apparent that the operating system should have little say in the “standard color map” in a modern specification.

Like most things in technology, age and wide-usage is not a indicator of a good choice. After all, modern standards should not restrict themselves on legacy limitations like 4bit (16 colour) palettes. Perhaps a clarification from Apple who contributed and approved this standard could explain why a Windows Operating System colour palette was chosen.

The claim that SVG conflicts with other W3C standards is in itself fanciful. By looking at published specifications, according to 'Basic HTML data types / Color', the standard color map for HTML are as follows:

Compare this with the SVG Colours:

We can clearly see that all the colour names and colour values of SVG have no conflict with the older and widely used W3C colour names and values defined in HTML. (i.e. Lime, Maroon, Teal, Aqua, Blue, etc. are identical in RGB values)

"Section 2.18.46 (of the Markup Reference volume) is about text *highlighting* color -- for highlighting over text, not a normal color or color settings used elsewhere. There is only one listed reference to this standard type from elsewhere in the specification and it is for highlighting text in WordML. There are a fixed number of values (you can't specify your own code), so color coded-names must be used in OOX for the hightlighting attribute, but we know what the corresponding codes are. The human-understandable names (not color-attribute values) all say "Highlight Color" quite prominently. This is apparently not a place where anyone things having rigorous precision for these color name-codes is a big deal. They don't apply to SVG or to DrawingML at all."

Section 2.18.46 of colour highlighting is a clear enumeration value, i.e. the colour values are not encoded. This, as described in comments, is in itself is contradictory to most of the other colour definitions in Ecma 376 where RGB values are used.

This self contradiction is worth elaborating on.

I recommend that the colour choice should be an application based decision. A standard can define what format a colour would be encoded in, but should not restrict what colour ranges a palette should take up.

What happens if a document needs more than 16 highlight colours? In the case of multiple users editing a collaborative document over the internet, it is nowadays easy to have more than 16 authors editing one document, with each having his or her own 'highlighter' colour.

So would limiting the number of colours for highlighting in the MSOOXML specification be a barrier for future use of this specification in Web 2.0 applications? I think this an unnecessary restriction.

So there are two recommendations Ecma can take from this contradiction.

1. It would be so much better if Section 2.18.46 did not need to contradict and redefine the 16 HTML colours. Instead it should reference the more widely used standards in W3C. It would have saved the spec 3 pages (only 0.05% savings, but we take what we can), but more importantly it would give the standard more consistency. It would also show that Ecma and Microsoft  are open to leverage on more openly defined and widely used standards from other bodies.

2. We have moved on from the days of limited colour pallettes in our video cards. Modern video cards can produce at least 24bit (16 million) colours. As a modern specification, Ecma 376 should also have the flexibility to encode whatever RGB values for a highlight colour. So to be consistent with the rest of the specification, MSOOXML should allow any RGB value to be used as a syntax for its highlight colour definition. Dont use enums, use RGB.

These recommendations are not overly demanding, and I think reasonable if Ecma/Microsoft are intent in making this a useful standard.

“With regard to Drawing ML (section 5.1), section 5.1.12.48 specifies Preset Color Values that are only used within that format. In this portion of the specification, the code values are identical to the SVG ones you offer, although the coded-names (which do not in any way use SVG namespaces) abbreviate "dark" to "dk" and "light" to "lt". These are strictly-defined and perfectly convertible between SVG and DrawingML, without any loss and with no mystery.”

In the commentary, I have already noted that the RGB values defined in MSOOXML are the same as the SVG values. I also noted that there was the strange abbreviation of “dark” to “dk” and “light” to “lt”. I questioned the reason for this change in names. I made a separate commentary on the bizarre naming conventions of MSOOXML, and these inconsistent truncations, abbreviations and raised concerns that these contradictory names is unnecessary and confusing.

In the case of "Preset Color Values" (5.1.12.48 page 4531) and SVG, we just have to wonder why Microsoft completely missed this wonderful opportunity to harmonize and leverage on W3C's definition of colours. Instead it took the "closed" route by redefining its own set of colours and subverting the names making future harmonizations difficult by the arbitrary abbreviations.

This is another clear example that Microsoft/Ecma has complete disregard for existing well established and modern standards, and always prefers to do things their own way, to the detriment of users and developers.

“Some conflict.”

Admittedly, in isolation, this does not look like a big deal. After all its just a few pages in 6000 right? But if you find the same minor issues of unnecessary limitations and inconsistencies cropping up in the specification over and over again, it does become a big deal.

This concern also highlights [pun may be intended] the frustrations developers would have to face when implementing the rest of the 6000 pages. The arbitrary selection of names and values, the disregard for existing standards and the refusal to adopt other better established standards is the reason why Ecma 376 has severe problems as an international standard.

“I haven't checked carefully, bit I wonder if it would be a good idea to examine ODF to make sure it doesn't have any similar "contradiction" before pouncing on OOXML.”

Nice try.

The issue at hand here is about the contradictions of MSOOXML. ODF already had its specification scrutinized during the 1 year ISO process in 2005-2006. Its MSOOXML's time to shine! Please stay on topic.

yk.

[Update: Sam Hiser of PlexNex has a link to my original post, entitled "MOOXML is Off Color" of which this commentor contributed first.]

Comments

[John Drinkwater]

Well researched and said!
Thankyou.

[Rob Weir]

I like the suggestion to allow the specification of RGB values rather than being forced to pick from a list of 16. We need to consider printed output as well, where specific colors may be desired in order to match a company's branding.