Windows Color System Common Profile Types schema, Versioning and Localization Strategies
Contents of This Page:
WCS Common Profile Types Schema
WCS Profile Schema Versioning Strategy
WCS Profile Localization Strategy
WCS Common Profile Types Schema
These types are used in the WCS profile schemas that follow this appendix. Only UTF-8 or UTF-16 encodings are supported. All other XML encodings are strongly discouraged in order to preserve optimum interoperability.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
xmlns:xs="https://www.w3.org/2001/XMLSchema"
xmlns:wcs="https://schemas.microsoft.com/windows/2005/02/color/WcsCommonProfileTypes"
targetNamespace="https://schemas.microsoft.com/windows/2005/02/color/WcsCommonProfileTypes"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
blockDefault="#all"
version="1.0">
<xs:import namespace="https://www.w3.org/XML/1998/namespace" />
<xs:annotation>
<xs:documentation xml:lang="en">
Common types used in WCS profile schemas.
Copyright (c) Microsoft Corporation. All rights reserved.
</xs:documentation>
</xs:annotation>
<xs:simpleType name="NonNegativeFloatType">
<xs:restriction base="xs:float">
<xs:minInclusive value="0"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="NonNegativeCIEXYZType">
<xs:attribute name="X" type="wcs:NonNegativeFloatType" use="required"/>
<xs:attribute name="Y" type="wcs:NonNegativeFloatType" use="required"/>
<xs:attribute name="Z" type="wcs:NonNegativeFloatType" use="required"/>
</xs:complexType>
<xs:simpleType name="GUIDType">
<xs:restriction base="xs:string">
<xs:pattern value="\{[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}\}"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="LocalizedTextType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang" use="required"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="MultiLocalizedTextType">
<xs:sequence>
<xs:element name="Text" type="wcs:LocalizedTextType" minOccurs="1" />
</xs:sequence>
</xs:complexType>
</xs:schema>
WCS Profile Schema Versioning Strategy
In this Appendix, the term "profile consumer" refers to the WCS software, or to a third-party software component that consumes WCS profiles.
We anticipate that in the future we will extend the WCS profile schemas with new features. Newer versions of profile consumers will be able to consume WCS profiles written according to older versions of the schemas.
To take full advantage of features defined in the newest version of the schemas, the newest version of a profile consumer will generally be required. But to the greatest extent possible, we also want to allow older profile consumers to consume profiles written according to newer versions of the schemas. The profile consumer will ignore XML elements and attributes that it does not understand. The results will be correct, but performance or fidelity might not be as good as could be achieved with the newest version of the profile consumer.
To accomplish this goal, the profile schema versioning strategy is set forth in the Office Open XML File Formats standard. The elements of our profile schema versioning strategy are:
- Each new schema version will introduce a new XML namespace URI (hereinafter referred to as a version namespace). All attributes and elements introduced in that version will be members of that version namespace.
- A given version of a profile consumer must recognize either all of the elements and attributes from a version namespace, or none of them.
- If a profile consumer encounters an element or attribute from a namespace that it does not understand, it must treat this as an error condition, unless the profile contains explicit guidance on fallback processing.
- The Open Packaging Specification defines an additional namespace URI, the markup compatibility namespace, which defines elements and attributes that provide this fallback processing guidance.
- All versions of all profile consumers must recognize and respect all the elements and attributes in the markup compatibility namespace.
- Profile consumers based on a new version of the profile schemas must support all previously defined version namespaces.
In the initial release, WCS will recognize elements and attributes from the following namespaces:
- https://schemas.microsoft.com/windows/2005/02/color/ColorDeviceModel
- https://schemas.microsoft.com/windows/2005/02/color/GamutMapModel
- https://schemas.microsoft.com/windows/2005/02/color/ColorAppearanceModel
Future version namespaces will have similar URIs, except for the year/month components of the names, for example:
https://schemas.microsoft.com/windows/2007/08/ColorAppearanceModel.
It will also recognize and respect the elements and attributes defined in the markup compatibility namespace:
Consider this example:
<?xml version="1.0" encoding="utf-8" ?>
<ColorAppearanceModel
xmlns=https://schemas.microsoft.com/windows/2005/02/color/ColorAppearanceModel
xmlns:cam2=https://schemas.microsoft.com/windows/2007/08/color/ColorAppearanceModel
xmlns:mc=https://schemas.microsoft.com/winfx/2005/02/markup-compatibility
xs:schemaLocation="https://schemas.microsoft.com/windows/2005/02/color/ColorAppearanceModel ColorAppearanceModel.xsd"
xmlns:xs='https://www.w3.org/2001/XMLSchema-instance'
mc:Ignorable="cam2"
>
<ProfileName>Default profile for ICC viewing conditions</ProfileName>
<mc:AlternateContent>
<mc:Choice Requires="cam2">
<cam2:AudioDescription source="ProfileExplanation.wav"/>
</mc:Choice>
<mc:Fallback>
<Description>Appropriate for a print in a D50 viewing booth</Description>
</mc:Fallback>
</mc:AlternateContent>
<Author>Microsoft Corporation</Author>
<ViewingConditions>
<WhitePointName>D50</WhitePointName>
<Background X="19.3" Y="20.0" Z="16.5" />
<Surround>Average</Surround>
<LuminanceOfAdaptingField>31.8</LuminanceOfAdaptingField>
<DegreeOfAdaptation>-1</DegreeOfAdaptation>
<cam2:Humidity>30%</cam2:Humidity>
</ViewingConditions>
</ColorAppearanceModel>
This profile uses elements from both the initial release of the CAMP schema, and a hypothetical future version 2007/08 of that schema. It also uses elements from the markup compatibility namespace. The mc:Ignorable attribute on the root element tells the profile consumer that it is free to ignore elements from the 2007/08 version namespace.
The Windows Vista version of WCS recognizes only the 2005/02 elements. Therefore it uses the 2005/02 Description element instead of the 2007/08 AudioDescription element, and ignores the 2007/08 Humidity element.
If the 2007/08 version namespace were not specified as Ignorable, then the presence of the cam2:Humidity element with no Fallback would cause the Windows Vista version of WCS to reject the profile as invalid. Presumably the 2007/08 version of WCS would recognize the elements of the 2007/08 version namespace.
For full details of the markup compatibility namespace, see the Open Packaging Specification, Appendix B. At the time of this writing, the plan of record is to fully implement all elements, attributes, and attribute values as defined in that specification.
WCS Profile Localization Strategy
Requirements
WCS profiles contain certain elements such as ProfileName and Description which contain human-readable text. This text must be localizable. The localization strategy must meet two requirements:
- For profiles created by 3rd parties such as printer manufacturers, the profile author must be able to incorporate descriptive text in multiple languages. This is necessary for parity with ICC profiles, which (in ICC Version 4.0 and later) use the multiLocalizedUnicodeType data type for tags containing localizable text.
- For standard profiles distributed with the Windows OS, the Windows Color CPL user interface must be able to display the descriptive text in any language, including languages that were not available when the profiles were first shipped.
The following elements must be localizable:
| Element | CDMP | GMMP | CAMP |
| ProfileName | x | x | x |
| Description | x | x | x |
| Author | x | x | x |
Expressing localizable elements
Instead of directly containing text, each localizable element contains one or more wcs:Text sub-elements, each of which must specify the xml:lang attribute. As described in the XML specification Section 2.12 ("Language Identification"), the value of the xml:lang attribute must be an IETF RFC 3066 language identifier such as "en-US", "en", or "fr-FR". In WCS schemas, the value of the xml:lang attribute must not be the empty string "", even though XML allows this in the general case. For example:
<cdm:ColorDeviceModel ... />
<cdm:Description>
<wcs:Text xml:lang="en-US">My hovercraft is full of eels.</wcs:Text>
<wcs:Text xml:lang="fr-FR">Je ne parle pas le français trop bien.</wcs:Text>
</cdm:Description>
...
</cdm:ColorDeviceeModel>
No two wcs:Text elements can have the same xml:lang attribute. Each WCS profile schema must enforce this constraint separately for each localizable element. Only UTF-8 and UTF-16 encodings are supported.
Schema Support
The design makes use of the XSD types wcs:LocalizedText and wcs:MultiLocalizedType defined in the WCS Common Profile Type schema:
<xs:complexType name="LocalizedText">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute name="xml:lang" type="xs:string" use="required"/>
<xs:extension/>
<xs:simpleContent/>
</xs:complexType/>
<xs:complexType name="MultiLocalizedType">
<xs:element name="Text" type="cam:LocalizedText" minOccurs="1"/>
</xs:complexType>
Each WCS profile schema declares each localizable element to be of type MultiLocalizedType, for example:
<xs:schema
xmlns:xs="https://www.w3.org/2001/XMLSchema"
xmlns:cdm="https://schemas.microsoft.com/windows/2005/02/color/ColorDeviceModel"
xmlns:wcs="https://schemas.microsoft.com/windows/2005/02/color/WcsCommonProfileTypes"
targetNamespace=
"https://schemas.microsoft.com/windows/2005/02/color/ColorDeviceModel"
version="1.0">
<xs:import namespace=
"https://schemas.microsoft.com/windows/2005/02/color/WcsCommonProfileTypes"/>
<xs:element name="cdm:Description" type="wcs:MultiLocalizableType" minOccurs="0"/>
<xs:unique name="uniqueDescriptionLanguage">
<xs:selector xpath="cdm:ColorDeviceModel/cdm:Description/wcs:Text"/>
<xs:field xpath="@xml:lang"/>
</unique>
...
</xs:schema>
The CDMP schema enforces the constraint that each wcs:Text child of the cdm:Description element must have a unique xml:lang attribute. It enforces the same constraint for the other localizable elements. The CAMP and GMMP schemas do the same.
Selecting the Language
When deciding which language version of a localizable element to display, application code should select the "closest version" to the "current language". What "closest version" and "current language" actually mean is platform-dependent; see below. If the profile does not contain a language version that matches the current language, the application should select the first version in the profile (the first wcs:Text child element of the localizable element).
On Windows Vista, the language selection is done as follows: Each thread has an associated list of "preferred UI languages", which can be obtained by calling the Vista-only API GetThreadPreferredUILanguages. The list is returned in order of user preference. For instance, on a system set up for US English, the list returned by GetThreadPreferredUILanguages is { "en-US", "en" }. This means: 1) US English if present. 2) Otherwise, use any regional variant of English, such as "en-GB" or just plain "en".
For each language in that list, in list order, the UI code looks for a wcs:Text element whose xml:lang attribute is an exact match. The first matching version is used. If no version matches, the first wcs:Text element is used.
Built-in profiles
The standard WCS profiles shipped with Windows Vista, such as sRGB.cdmp, have the same localizable properties as other profiles. But there is an additional requirement on these profiles: we must be able to display their properties in every language that we ship Windows in. It is impractical to shoehorn hundreds of language translations into the standard system profiles, and even if it were not, that wouldn't help when we released a new language pack.
The standard Windows solution would be to put the localized strings in a MUI DLL, and refer to them like this:
<cdm:Description resourceId="mscms.dll,-101">
<wcs:Text xml:lang="en-US">Hello, world!</wcs:Text>
<cdm:Description>
On a Windows system, the description text would be extracted from resource ID 101 in the appropriate localized version of the MUI resources for mscms.dll. Non-Windows systems would use the wcs:Text sub-elements as described above.
We introduce an optional, globally unique ID attribute on the root element of each WCS profile schema. The standard profile wcsRGB.cdmp might look like this:
<cdm:ColorDeviceModel
ID=https://schemas.microsoft.com/2005/02/color/profiles/wcsRGB.cdmp
... >
<cdm:Description>
<wcs:Text xml:lang="en-US">Hello.</wcs:Text>
<wcs:Text xml:lang="fr-FR">Bonjour.</wcs:Text>
</cdm:Description>
...
</cdm:ColorDeviceModel>
The Window system has special knowledge of the IDs corresponding to the standard Windows profiles. It knows the resource IDs for each localizable element of each standard profile. When the UI code displays profile properties, it first looks at the ID. If it is present, and if it is one of the standard recognized IDs, Windows extracts the properties from the resource DLL instead of from the wcs:Text sub-elements.
See Also
Basic Color Management Concepts, Windows Color System Schemas and Algorithms