Some definitions are duplicated in more than one schema modules. (A list of definitions having the same name is attached.) Such duplications are particularly harmful, when the duplicated definitions are changed inconsistently in the future. A good example is the simple type "ST_Guid", which has a rather complicated pattern facet "\{[0-9A-F]{8}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{4}-[0-9A-F]{12}\}". This simple type is defined five times by dml-baseTypes.xsd,shared-customXmlDataProperties.xsd, sml-baseTypes.xsd, vml-officeDrawing.xsd, and wml.xsd. They are likely to be changed inconsistently in the future.

Reorganize the schemas so that no definitions are duplicated.

Part4 Annex A

te

Proposed Disposition of DIS 29500 Comment JP-0077 (Modified: 2008-01-10) We agree that identical definitions should be avoided within the specification, for the reasons stated in the comment. Office Open XML makes full use of XML namespaces (http://www.w3.org/TR/xml-names/). As such, elements, attributes, complex types, and element groups with similar unqualified names actually define content models in different namespaces, each of which are specific to the markup language within which they are contained. However, we agree that the presence of simple types with identical names, which are not affected by XML namespaces, is a potential for concern and should be avoided. To avoid this condition, the schemas will be updated as follows: A new schema ­ shared.xsd ­ will be created to hold all shared simple type definitions. The following simple type definitions will be moved to this schema: o ST_AlgClass o ST_AlgType o ST_CalendarType o ST_ColorSchemeIndex o ST_ColorType o ST_CryptProv o ST_Guid o ST_OnOff o ST_Panose o ST_RelationshipId o ST_String o ST_TextDirection o ST_TextLanguageID o ST_TrueFalse o ST_TrueFalseBlank o ST_TwipsMeasure o ST_VerticalAlignment o ST_VerticalAlignRun o ST_XAlign o ST_Xstring o ST_YAlign Existing instances of these simple types in other schemas will be removed. References to the removed simple types will now point to their shared counterparts. As well, the following simple types define different value spaces within different markup languages; in these cases the names of these types will be updated to reflect that these are different and should be allowed to evolve independently in the maintenance process: ST_Angle ST_Direction ST_EditAs ST_FillType ST_HorizontalAlignment ST_Jc ST_Orientation ST_SourceType ST_Style ST_TextAlignment As well, we believe that further consolidation is an important goal which should be part of the maintenance process for the specification, when the future evolution of each markup language can be taken into account.