Schema Annexes

From OOXML-Wiki

Contents 1 Schema annexes 1.1 Incorrect use of xml:import 1.2 No schemaLocation for XML namespace 1.3 Conflicting simple type definitions within XML schema 1.3.1 ST_AlgType 1.3.2 ST_AlgClass 1.3.3 ST_CalendarType 1.3.4 ST_ColorSchemeIndex 1.3.5 ST_CryptProv 1.3.6 ST_HorizontalAlignment 1.3.7 ST_OnOff 1.3.8 ST_TextAlignment 1.3.9 ST_TrueFalseBlank 1.3.10 ST_TwipsMeasure 1.3.11 ST_VerticalAlignment 1.3.12 ST_YAlign

[edit] Schema annexes

[edit] Incorrect use of xml:import

The OOXML XML Schemas use xml:import incorrectly. Stylesheets contain multiple import statements, each giving the same namespace, but different schemaLocation hints. It is ambiguous whether this is legal XML Schema, but it goes against the intention of the XML Schema specification (Noah Mendelsohn), is not supported by several major validation tools (e.g. XSV, Xerces 2.9, at least some versions of Tibco Turbo, and older versions of MSXML), and is not an approach recommended by XML Schema experts (Jeni Tennison, Michael Kay). Remedy: Build an "adapter schema" which is imported in place of the multiple existing imports, which uses xs:include directives to include all the schemas that reference the same namespace.

Affects files: dml-chart.xsd, dml-chartDrawing.xsd, dml-compatibility.xsd, dml-diagramColorTransform.xsd, dml-diagramDataModel.xsd, dml-diagramDefinition.xsd, dml-diagramElementPropertySet.xsd, dml-diagramElementPropertySet.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-diagramStyleDefinition.xsd, dml-lockedCanvas.xsd, dml-picture.xsd, dml-spreadsheetDrawing.xsd, dml-spreadsheetDrawing.xsd, dml-spreadsheetDrawing.xsd, dml-spreadsheetDrawing.xsd, dml-spreadsheetDrawing.xsd, dml-wordprocessingDrawing.xsd, pml-animationInfo.xsd, pml-comments.xsd, pml-embedding.xsd, pml-presentation.xsd, pml-presentation.xsd, pml-presentation.xsd, pml-presentationProperties.xsd, pml-slide.xsd, pml-viewProperties.xsd

[edit] No schemaLocation for XML namespace

OOXML XML Schemas reference xml:space as an attribute value, but don't provide a schemaLocation for the schema for the XML namespace. Although this is legal XML Schema (the schemaLocation is a hint, rather than required), it imposes an unnecessary complication on using the schema (since the schema location must be specified separately, either automatically by the validator as MSXML does, or using a catalog as most other tools do). Remedy: Alter the stylesheets (wml.xsd, shared-math.xsd) which import the xml namespace to include a schemaLocation of http://www.w3.org/2001/xml.xsd.

Affects files: wml.xsd, shared-math.xsd

[edit] Conflicting simple type definitions within XML schema

In a number of places within the schema, the same simple type is defined within different parts of the schema with different definitions. For example, ST_OnOff in shared-math.xsd allows "on" and "off" as values; ST_OnOff in wml.xsd allows "on", "off", "true", "false", "0", "1".

[I will attempt to find the time to write some schema processing code to find any other conflicting definitions within the schema - Inigo. Update - I've written code to find conflicting definitions. The vast majority of definitions that appear in more than one schema are different in some way, ranging from simple differences in the documentation, to actual conflicts in allowed values.]

In the following analysis of conflicting definitions, I am restricting myself to commenting on those definitions which have the same type name, and are clearly intended to do the same thing. There are a number of other definitions which share the same name, but are intended to do different things (such as ST_Direction in DML and PML, and less clearly ST_Angle in DML and VML) - these are confusing but not as serious as the descriptions below.

[edit] ST_AlgType

ST_AlgType is defined in wml.xsd and in pml-presentation.xsd. In the former, it allows value typeAny. In the latter, it allows values typeAny and invalid. It is unclear why it is legal to specify an invalid algorithm, and no behaviour is specified if an invalid algorithm is provided. Remedy: Rationalize on the former.

[edit] ST_AlgClass

ST_AlgClass is defined in wml.xsd and in pml-presentation.xsd. In the former, it allows value hash. In the latter, it allows values hash and invalid. It is unclear why it is legal to specify an invalid algorithm class, and no behaviour is specified if an invalid algorithm is provided. Remedy: Rationalize on the former.

[edit] ST_CalendarType

ST_CalendarType is defined in sml.xsd and in wml.xsd. In the former, it allows values none, gregorianUs, gregorianMeFrench, and gregorianMeArabic that are not present in the latter. In the latter, it allows the value saka not present in the former. All sections of a standard should support the same calendars. Remedy: Combine the valid calendar types into a single definition of valid calendars.

[edit] ST_ColorSchemeIndex

ST_ColorSchemeIndex is defined in wml.xsd and in dml-baseStylesheet.xsd. In the former, it allows values dark1, light1, etc. hyperlink and followedHyperlink. In the latter, it allows values dk1, lt1, etc. hlink and folHlink. Remedy: Rationalize to the former.

[edit] ST_CryptProv

ST_CryptProv is defined in wml.xsd and in pml-presentation.xsd. In the latter it allows the value "invalid". It is unclear why it is legal to specify an invalid cryptographic provide, and no behaviour is specified if an invalid provider is provided. In addition, in the former, the rsaFull value is described as "Any provider" rather than "RSA Full Encryption Scheme" as it is in the latter. Remedy: Remove "invalid" as a value. Correct the documentation in the schema.

[edit] ST_HorizontalAlignment

ST_HorizontalAlignment is defined in sml.xsd and dml-diagramTypes.xsd. In the former, it takes values "left", "right", "center". In the latter, it takes values "l", "r", "ctr". Terminology should be consistent within a standard. Remedy: Change "l", "r" and "ctr" in the latter to match the "left", "right", "center" values in the former.

[edit] ST_OnOff

ST_OnOff in shared-math.xsd allows "on" and "off" as values; ST_OnOff in wml.xsd allows "on", "off", "true", "false", "0", "1". Remedy: rationalize the schema definitions so the type does not conflict, preferably by restricting wml.xsd to only allow "on" and "off".

[edit] ST_TextAlignment

ST_TextAlignment is defined in wml.xsd and dml-diagramTypes.xsd. In the former, it takes values "left", "right", "center". In the latter, it takes values "l", "r", "ctr". Terminology should be consistent within a standard. Remedy: Change "l", "r" and "ctr" in the latter to match the "left", "right", "center" values in the former.

[edit] ST_TrueFalseBlank

ST_TrueFalseBlank is defined in vml-officeDrawing.xsd and vml-spreadsheetDrawing.xsd. In vml-officeDrawing, it takes values "true" and "false" (among others). In vml-spreadsheetDrawing, these values must be "True" or "False". Terminology should be consistent within a standard. Remedy: Change "True" and "False" in the latter to "true" and "false".

[edit] ST_TwipsMeasure

ST_TwipsMeasure is defined in shared-math.xsd and wml.xsd. In the former, it is an xsd:unsignedInt. In the latter, it is an ST_UnsignedDecimalNumber, which maps to an xsd:unsignedLong. The same type name should not have different ranges in different parts of the specification. Remedy: Change ST_TwipsMeasure to use xsd:unsignedLong throughout.

[edit] ST_VerticalAlignment

ST_VerticalAlignment is defined in sml-styles.xsd and in dml-diagramTypes.xsd. In the former, it can be top, center or bottom (among other values). In the latter, these are "t", "mid" or "b". Terminology should be consistent within a standard. Remedy: Change the latter to use "top", "center" and "bottom" in place of "t", "mid" and "b".

[edit] ST_YAlign

ST_YAlign is defined in shared-math.xsd and wml.xsd. In the former, it allows the value "bot". In the latter, the corresponding value is "bottom". Terminology should be consistent within a standard. Remedy: Change the former to use "bottom".