Section 2.6

The requirements presented as necessary for interoperability only addresses a part of the problem. Apart of what is mentioned, it is also important to properly limit and define the use of extensions, as this will inevitably lead to problems of interoperability and portability, since documents using undocumented extensions will be valid OOXML documents, but will make the document unreadable by different applications than the one which created it.

Enforce interoperability throughout the standard. A document-producing application must inform the user when extensions which will break interoperability and portability are used, to avoid misleading the user into thinking that particular document can be consumed by any other OOXML compliant application. The standard should mandate the use of some mechanism to mark the document as “extended”, e.g. a warning message or a different document extension. Sections which include non-portable extensions in Part 4 include: 2.3.3.17, 2.16.5.33, 2.16.5.34, 2.17.3, 3.2.7, 4.6.9, 4.6.68, 4.6.69, 4.6.70, 4.6.93, 5.1.3.2, 5.2.3.4, 5.1.3.6, 5.1.3.7, 6.1.2.19

Section 9.1

According to this point (Constraints on Office Open XML's Use of OPC), OPC, Open Packaging Conventions, are more general than needed for the purpose of OOXML. This is due to bring confusion, and should be resolved

Propose OPC as a separate standard.

2.3.1

Closing quotes missing in example

Fix

2.4.2

The word “emphasized” must be in italics to agree with the example

Fix

2.4.2

tag <w:rPr> should be</w:rPr>

Fix

2.4.2

The sentence “the properties of only some the text” is not complete

Fix

2.5.2

Use straight quotes instead of curly

Fix

2.5.4

“World” should not be capitalized to agree with example

Fix

2.6.2

www.contoso.com points to the Microsoft Office website

Use a neutral example

2.6.2

www.contoso.com points to the Microsoft Office website

Use a neutral example

2.8.2

“heading 1” should “Heading 1” to agree with the text

Fix

2.8.2

The example is repeted

Remove the duplicate text

2.8.6

Element <w:style> has no child <w:priority>.

Fix

2.8.11

Element <w:latentStyles> has no child <w:defPriority>.

Fix

2.8.11

Element <w:style> has no child <w:priority>.

Fix

2.14.7

Code should read “Some “ (including white space) to agree with example

Element <w:style> has no child <w:priority>.

3.16.9

In the 1900 date base system, the lower limit is January 1, 1900.

Remove this unnecessary restriction and allow better date support. Allow negative values in the serial number or define a system counting from an earlier date (e.g. 0 A.D.)

5.8.4.1

Code formatting differs from the rest of the standard. It is a graphic and has no line numbers

Fix

5.8.4.3

Code formatting differs from the rest of the standard. It is a graphic and has no line numbers

Fix

5.8.5.3

Code formatting differs from the rest of the standard. It is a graphic and has no line numbers

Fix

5.9.2.1

The definition for the unit EMU should be stated as 91440 EMU = 1 U.S. Inch and 36000 EMU = 1 cm.

Fix

5.9.4.3.1

Use straight quotes instead of curly ones

Fix

5.12.3.1.1

The example presents invalid XML

Fix

5.12.3.1.3

The example presents invalid XML

Fix

5.14.3

The example presents invalid XML

Fix

5.14.3.1.1

The example presents invalid XML

Fix

5.15.3.1.3

Missing closing quotes for attribute “maxOccurs”

Fix

5.15.4.1

Missing closing quotes for attribute "name"

Fix

5.15.4.1.6

Missing closing quotes for attribute "name"

Fix

5.15.5.1.3

Invalid character at end of line

Remove

5.15.6.3.16

Attribute “animLvl” is not closed with quotes and has no white space to separate it from next attribute “type”

Fix

7.1

The description for OMath in this informative section is not detailed enough for the purpose of this section, especially when compared to the rest of the sections in this part. It has no code examples like the rest of the sections.

Make the text more detailed and consisten with the other sections

7.1

Duplicate expressions

Remove duplicates

7.1.10

Expression "x+x+x" is used, and below it appears as "x+x+..."

Fix

7.2.1

Invalid XMl in example

Fix

8.1

Code formatting is not consistent with the rest of the standard because it is in italics. For consistency use of double quotes instead of apostrophe is preferred.

Fix

8.3.4.1.1

The image is practically unreadable because of resolution and background color

Fix

2.2.1

Background elements are defined as using VML. However, Part 1, Section 8.2.6 says, “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”. In this case, even new documents must use VML to specify backgorunds.

Remove references to VML and substitue for DrawingML.

2.2.1

The sentence 'or auto to allow a consumer to automatically determine the background color as appropriate.' does not define the appropriate behavior of the consumer, whereas the definition of the corresponding simple type, found in Part 4, page 1737, explicitly states that 'This value shall be used to specify an automatically determined color value, the meaning of which is interpreted based on the context of the parent XML element.'

Define the characteristics of the auto value for the color attribute of the background element properly.

2.3.1.8

The element “cnfStyle” uses a bitmask to specify various paragraph conditional formatting properties.. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations.

Rewrite this subclause to express the feature using XML constructs rather than bitmasks.

2.3.2.1

It is desired to have improved interoperability between ODF and OOXML. However, OOXML text runs only support two font weights, bold or normal, where ODF supports the fuller range of font weights from XSL-FO

Include support for additional font weights, 100, 200, 300, 400, 500,600. 700, 800 and 900.

2.3.3.17

The type of video element allowed is not specified. Use of propietary codecs will break portability of a document, and may present patent problems for implementation, since they are outside of the scope of this specification.

Specify a set of patent free, portable video codecs as base, and whenever other codecs are used, mark the document as “extended” (See comment for Part 1, Section 2.6)

2.3.3.21

The object element is used for embedding inline objects. However the text says “The layout properties of this embedded object are specified using the VML syntax”. VML is in the specification for legacy reasons only (See comment for 2.2.1). All OOXML consumers would need to support VML, even where legacy documents are not present.

Remove this element as there is already an element in section 2.3.3.9 which can embed DrawingML objects.

2.4.8

This element uses bitmasks to specify various table row formatting properties. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations.

Rewrite this subclause to express the feature using XML constructs rather than bitmasks.

2.4.51

This element uses a bitmask to specify various table style formatting properties.. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations.

Rewrite this subclause to express the feature using XML constructs rather than bitmasks.

2.8.2.2

This value is said to signify “an Eastern European character set”. There is no such thing. First, “Eastern Europe” is not unambiguously delineated. Second, this region uses many character scripts, including Roman, Cyrillic, Arabic, Armenian, etc.

Explain what is meant by, “an Eastern European character set”.

2.8.2.16

Use of bit masks is not the right way in XML. This element of the specification uses a set of bitmasks to specify which code pages a given font supports. The use of bitmasks rather than an XML Schema derived type makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations. One of the advantages of XML is that we don't need to encode data like this any more.

Rewrite this subclause to express the feature using XML constructs rather than bitmasks.

2.15.1.28

The algorithm given here is new and has not undergone peer review. Even though this is an application-enforced security feature, a strong known and tested algorithm should be used.

Use a recognized standard cryptographic hash algorithm like SHA-256, Whirlpool, etc.

2.15.1.28

This algorithm description fails to specify the encoding of the input password. The described algorithms make use of byte-level manipulations which depend on the machine architecture (big endian versus little endian). So it is necessary that all byte ordering assumptions be made explicit.

Make the byte ordering assumptions explicit, both for the input password and the processing steps, so as to allow cross-platform interoperability.

2.15.1.86

This element uses a bitmask to specify a style display filter. Use of bit masks is not the right way in XML.

Rewrite this subclause to express the feature using XML constructs rather than bitmasks.

2.15.2.32

The element “optimizeForBrowser” only accomodates Internet Explorer and Netscape Navigator. This section requires that “all settings which are not compatible with the target web browser shall be disabled.” There is no way to specify a standards compliant optimized output with PNG, MathML and SVG.

This clause should be rewritten to express this feature in an application and platform neutral way, allowing more versatility.

2.15.3.26

The “footnoteLayoutLikeWW8” element, is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.

2.15.3.32

The “mwSmallCaps” element, is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.

2.15.3.51

The “suppressTopSpacingWP” element, is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.

2.15.3.54

The “uiCompat97To2003” element is defined as: “Disable UI functionality that is not compatible with Word97-2003”. The standard must be application neutral.

Define this an application neutral way. If it is truly a Word-only feature, then remove it from OOXML and express as an application-defined extension.

2.15.3.64

The “useWord97LineBreakRules” element is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.

2.15.3.66

The “wpSpaceWidth” element is defined in terms of a particular application's behavior. The standard contains insufficient detail on how to replicate this behavior.

Define the intended behavior.

2.16.5.33

The field INCLUDEPICTURE says that it merely retrieves the picture contained in the named document. Is nothing else to be done with the picture? For example, should it be displayed?

Define what is to be done with the picture once it is retrieved.

2.16.5.33

No picture formats are listed as valid. There may be undocumented of patented picture formats, which will break portability of a document.

Define a set of documented and patent-free formats for pictures, and mark the document as “extended” when a different one is used. See comment for Part 1, section 2.6)

2.16.5.34

The INCLUDETEXT field “Inserts all or part of the text and graphics contained in the document named”. However, no mention is made of what formats are permissible for the retrieved text.

There should be specified at least a small set of interoperable formats. Whenever this element is used with a format not mandated by OOXML, an application must mark the document as “extended” (see comment for Part 1, Section 2.6)

2.16.5.5

According to the text, the AUTONUM field is deprecated. A new standard should not contain deprecated parts.

Remove all references to AUTONUM from the OOXML text and make sure LISTITEM includes all functionality necessary. The transforming application must handle the conversion.

2.17.3

The external content import elements in WordprocessingML put document interoperability at risk, since not even a common ground is defined. Any application can put any content (even the whole document in an application specific way) here and the file can still be considered valid OOXML.

It is necessary to set a common ground for external content, or declare that applications using this section are not OOXML comformant, to avoid misleading a user into thinking that a particular OOXML file can be viewed correctly by any application. One of OOXML's goals is interoperablity and application independence. Whenever this element is used, an application must mark the document as “extended” (see comment for Part 1, Section 2.6)

2.18.4

The borders lack proper definition, since no size, corner handling or additional files are given. No mechanism for expanding the set of art borders is provided. Since the specified art borders are heavily Western-oriented, it would be good to provide a way for an application to supplement these styles with graphics that provide more regional flavor.

Define the borders in detail. Provide an interoperable extensibility mechanism for a document author or application to specify their own art border graphics.

2.18.46

The list of highlight colors closely matches color codes in SVG 1.0 and ISO 15445, however there are innecessary divergences in a few colors like "darkBlue", "darkCyan" and "lightGray". Slight variations from widely used standards create confusion and are a source of errors.

Follow previous standards and either reference SVG 1.0 or ISO 15445, or compile a list that follows these standards

2.18.52

The type “ST_LangCode”is defined as containing, a two digit hexadecimal language code”. It is fruther stated that, “This simple type's contents must have a length of exactly 2 characters”. However, two hex digits can count up to 255 and the values enumerated in this clause go far beyond that.

Refine the definition of this function, especially with respect to pre-metric measures so as to remove ambiguity.

2.18.66

The formatting system described here (ST_NumberFormat) is not clear. It lacks support for Armenian, Tamil, Greek alphabetic, Ethiopic and Khmer numerations, all in use today, as well as the various historical systems still used by scholars.

Use a more flexible, extensible, generative approach to numeration, such as that used by the W3C's XSLT standard in their xsl:number support

2.18.66

Format is defined in reference to the “Chicago Manual of Style”, but no edition or page reference is provided.

Either include the entire definition in the standard, or provide a proper external reference.

2.18.66

Several counting systems are defined to use letters of the alphabet, but nothing is mentioned about how counting continues once the letters of the alphabet are exhausted.

Clarify the text to explicitly cover this case.

2.18.72

Length is said to be “exactly 10 characters”. This is inconsistent with the example given which has a length of 20 characters.

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

2.18.86

The definition of type “ST_ShortHexNumber” says it contains two hexadecimal digits, two hexadecimal octets and exactly two characters. These definitions are not compatible. A hexadecimal octet is two hexadecimal digits.

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

3.2.29

No normative description of the password hashing algorithm is provided, so interoperability of this feature cannot be assumed. In an informative section, 5-pages of C-language source code is provided as “an example”, and this appears to involve machine-dependent bit manipulations.

Provide a normative, cross-platform definition of the hashing algorithm. Cross-platform source code can be given as an example, but the normative text should be in English, not in a programming language.

3.2.29

This algorithm description fails to specify the encoding of the input password. Presumably it is Unicode, but in what encoding? UTF-16BE? UTF-16LE? UTF-16 with a BOM (Byte Ordering Mark)? The described algorithms make use of byte-level manipulations which depend on the machine architecture (big endian versus little endian). So it is necessary that all byte ordering assumptions be made explicit.

Make the byte ordering assumptions explicit, both for the input password and the processing steps, so as to allow cross-platform interoperability. Keep in mind that the hash may be calculated on a different machine architecture than the password was entered with.

3.2.29

A hash algorithm is provided to secure passwords, likely based on a legacy algorithm used in Excel. This legacy algorithm is known to be a weak algorithm and has effectively been cracked. One could argue that no hash algorithm would be effective in OOXML, since a user could simply unzip the document and hand edit the XML to remove the hash or to set it to some known value. However, some application types such as online editing via Google Docs, or other similar applications, can secure physical access to the document via other means. Editing access to the document does not necessarily presuppose physical access to the document's XML. So there is a necessity for a secure & interoperable hash algorithm, such as SHA-256 for document protection.

Use a standard, such ISO/IEC 10118-3:2004, compliant hash algorithm as the default. Other country specific standards could be acceptable such as FIPS-180 from NIST, but additionaly to glbal standards . Legacy hash algorithms should be supported via the described extension mechanism.

3.3.1.62

OOXML allows the inclusion of binary data for printer settings (DEVMODE), which presents a potential security risk.

These configurations should be expressed with proper XML, and since they are platform specific, there should be proper definitions for each platform.

3.3.1.69

The securityDescriptor attribute, “defines
user accounts who may edit this range without providing a password to access the range”. It is a string. But no information is given as to what user accounts are referred to here, or what the delimiter is. Are these comma-delimited local machine user accounts? Or semi-colon delimited LDAP DN's? There will be no interoperability if this is not defined.

Fully define this attribute.

3.17

The mathematical formula graphic given in many places borders on unreadable and compares very poorly with the clarify of the rest of the text and most other images (e.g. page 2552(2559) line 1, line 3).

Provide better quality mathematical formula graphics.

3.17.4.1

In the 1900 date base system, the lower limit is January 1, 1900, which is too recent.

Allow negative date serial values to express dates prior to 1900 or define a system which starts at an earlier date (e.g. 1 A.D.).

3.17.4.1

Two base systems are given, and while one is necessary for legacy compatibility, the second one introduces unnecesary restrictions like no dates before 1904. Processing dates before this year are a necessity in many applications.

Remove the 1904 date base system and replace with a system that begins at an earlier date, e.g. 0 A.D.

3.17.6.7

This calls for the date serial number to be stored, “as accurately as possible”. This requirement is not precise and is untestable.

State the minimum precision required.

3.17.7.9

It is not specified whether this function short-circuits or not. In other words, must the remaining arguments be evaluated once one of them is found to be FALSE? Since some functions have side effects, it is necessary to define this in order to ensure interoperability.

Specify whether this function allows short-circuit evaluation.

3.17.7.12

It is not indicated whether the returned value shall be in radians or degrees

Specify the angular units that should returned

3.17.7.15

It is not indicated whether the returned value shall be in radians or degrees

Specify the angular units that should returned

3.17.7.17

The function description has a typo/duplication: “cells with the value 0value 0”

Fix the typographical error

3.17.7.35

This function maps between numbers and characters. But this mapping must be defined by a character set and none is defined here.

Specify what character set is used for this mapping (ASCII?).

3.17.7.38

The definition of this function says the the results are “unspecified” if the two ranges do not have the same number of points. But isn't this a clear argument error where should be returned? Surely we can document what Excel does here?

Specify the required results for the case where the two ranges are of unequal size.

3.17.7.48

This function is ambiguously defined, especially with regards to the traditional units of measure. For example, a tablespoon is 15ml in the US, but 20ml in Australia. Which is meant here? Similarly, a cup is defined differently in various countries, e.g. 8 oz in US, except the FDA defines it for food labeling purposes as 240ml, while it is 250ml in Australia and 285ml in the UK. Also, the unit Pica is oncorrectly defined as 1/72 inch when it should be 1/72 foot.

Refine the definition of this function, especially with respect to pre-metric measures so as to remove ambiguity.

3.17.7.50

It is not indicated whether the parameter is in radians or degrees

Specify the angular units that this parameter is in

3.17.7.65

The definition of this function says that it retrieves an OLAP Cube from a “SQL Server”. Surely this function is not limited to use only against Microsoft database servers?

Provide a vendor-neutral definition of this function.

3.17.7.74

The definition of date normalization is rather loose. I think you want to say something like this; month is greater than 12, then month-12 shall be added to the first month in the year specified.”, etc. The problem with how it is stated is that “that” does not refer to anything in “that number of months”.

Clarify the definition of date normalization.

3.17.7.77

Normative information regarding the processing of “an entire column in a database” is placed in an informative note. Since it is clearly stating a requirement in the processing this should be in the normative text.

Rework the note into the normative description of this function.

3.17.7.91

The function is defined in terms of $100 face value, but there is nothing about the security discounting that is intrinsically tied to the US Dollar.

Recommend the use of the generic currency sign here (U+00A4)

3.17.7.96

The information marked as “Note” seems to contain the only definition of what this function actually should do, so it should be made part of the normative material.

Rework the note into the normative description of this function.

3.17.7.111

String comparisons in an international setting are typically described as either lexical comparisons where the strings are compared character by character for identity, and by collation comparisons where equivalent characters are considered identical. This function does not say which method it uses.

Clarify what defines two strings as having identical content.

3.17.7.119

Similar issue to EXACT. Is this a lexical comparison or collation-based?

Clarify the basis for finding substrings

3.17.7.123

The rounding algorithm is not specified. How for example, do we calculate FIXED(0.5,0)? Round up, round down?

State what the rounding conventions are.

3.17.7.144

The definition says that an allowed format for the link-location parameter is a “universal naming convention (UNC) path on a server”, though this term is not defined.

Provide a normative definition or reference for a UNC path.

3.17.7.201

This function is ambiguous. Is it asking for a lexical, character by character conversion to lowercase? Or for a whole-word conversion? For example, Greek capital Sigma has two lower case forms, one reserved for use as the terminal letter in a word. As written, it is not clear whether this function should be implemented to take that into consideration or not.

Clarify what it means to convert to lower case.

3.17.7.207

The text currently says, “If there is an even number of numbers in the set, MEDIAN calculates the average of the two numbers in the middle”. This is ambiguous. Middle of what? Middle of the range is the most direct interpretation. Probably want something more like, “The values in the range are logically ranked from lowest to highest and the middle number is returned. If there is an even number of numbers in the set...”

Clarify the definition.

3.17.7.229

This text says, “NORMSINV uses an iterative search technique”. This is specifying an implementation, not a testable performance criterion. Other approaches should be permitted.

Keep the suggestions, but put them in informative Notes or Guidance.

3.17.7.282

Is this a lexical comparison or collation-based search?

Clarify the basis for string comparisons

3.17.7.313

It is not indicated whether the parameter is in radians or degrees

Specify the angular units that this parameter is in

3.17.7.348

This function is ambiguous. Specifically it does not treat the calculation in the presence of leap years. In the Actual/Actual basis, do we ever divide by 366? Or only by 365? Would we divide by 366 only if the leap day is between start-date and end-date? Of either start-date or end-date are in the leap year? If both start-date and end-date are in a leap year?

Clarify the definition of the function when involving leap years.

4.3.1.35

The element "smartTags" is insufficiently defined for DrawingML. Is the behavior equivalent to the behavior in WorprocessingML?

Define the behavior of smart tags for DrawingML

4.6.68

The audio codecs allowed for the “snd” element are not specified. There are many propietary and non-portable codecs which would break portability of a document.

Define a set of patent-free portable audio codecs as base. Whenever other codecs are used, the document must be marked as “extended” (see comment for Part 1, Section 2.6)

4.6.70

The audio codecs allowed for the “sndTgt” element are not specified. There are many propietary and non-portable codecs which would break portability of a document.

Define a set of patent-free portable audio codecs as base. Whenever other codecs are used, the document must be marked as “extended” (see comment for Part 1, Section 2.6)

5

The new unit EMU (English metric units) is never properly defined and used in several places. e.g. Sections 5.1.12.42, 5.1.5.1.1, 5.1.12.16.

Produce a proper definition of EMU, clearly referenced when it is used, or use a standard unit of measure.

5.1.5.3.2

Smart tags are mentioned but they are not described elsewhere in the VML specification

Define the behavior of smart tags for VML

5.1.12.37

The Panose value is said to be used, “so that generating applications using this Office Open XML Standard may determine the closest font type if necessary”. However, no font distance metric or font matching heuristic is described.

Describe the intended font matching procedure.

5.1.12.37

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.

5.1.3.4

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. Since Quicktime is a propietary technology not covered within this specification, must cause the docuement to be marked as “extended” (See comment for Part 1, Section 2.6)

5.1.3.7

The attribute “builtIn” specifies whether a sound is builtIn and is to be reference by name only and not included within the file. Since no list of built-in audio files is given, this will break a document's portabilty, as no application but the creator will posses certain audio files.

For the sake of portabilty, this attribute should be removed. If this is not desired, provide a list and set of built-in audiofiles. As a last option, documents using this attribute should be marked as “extended” (see comments for Part 1, Section 2.6)

6.1.2.7

This element uses a bitmask to specify VML table properties. The use of bitmasks rather than a set of boolean types makes this data almost impossible to work with standard XML tools like XSLT which lack bit-level operations.

Rewrite this subclause to express the feature using XML constructs rather than bitmasks.

6.1.2.19

The "gfxdata" is defined as an encoded package whose contents are application defined. This lack of definition breaks interoperability as content placed here by an application may not be understood by another one.

It is suggested that this element, for the sake of interoperability be limited to a particular package type. If extensibilty is desired in this case mark the document as “extended” (see comment for Part 1, Section 2.6)

6.4.3.1

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.

Make standard neutral by adding options for other relevant platforms. The desire is to allow cross platform interoperability and efficiency.

7.1

OOXML is not compatible with the industry standard language for displaying mathematical equations — MathML — used by the research community and the most important publications as Science, Nature, etc... . No interoperability with MathML is in the OOXML specifications.

Add the pertinent interoperability with MathML

7.4.2.4

The presence of non-XML characters, escaped, or not escaped in an OOXML document, is contrary to interoperability of XML and XML-based tools. The W3C's Internationalization Activity confirms this interpretation, saying “Control codes should be replaced with appropriate markup. Since XML provides a standard way of encoding structured data, representing control codes other than as markup would undo the actual advantages of using XML. Use of control codes in HTML and XHTML is never appropriate, since these markup languages are for representing text, not data.”

Remove the bstr type from OOXML

7.4.2.5

This element defines usage on Windows and Macintosh platforms only, but it doesn't specify whether OS 9 or OS X, and leaves out other important operating systems like Linux.

Make standard neutral, defining values for other prominent systems.

7.5.2.1

The address at www.contoso.com points to the Microsoft Office product page.

Use a neutral example.