OASIS SDD TC Version ProposalDraft 2 after Jan. 2007 F2F

Brent A. Miller

STSM, IBM Corp.

Current State

• schemaVersion: <major.minor>– We control this– This is done

• versionStringType: <V.R.M.L>– We specify this– This is incorporated in the specification– Used in (PD).packageIdentity.IdentityType, (DD).resultingResource.backwardCompatibility, (DD).resource, (DD).resultingResource, (DD).root[x]U.identity, (DD).ResourceConstraintGroup.versionConstraint

– Blue = ones that we control and specify as VRML– We specify a version comparison algorithm

Problem Statement (1)

• We control the “make it up” version specifications– schemaVersion– Descriptor identities

• We do not control the “look it up” version specifications– Resource– resultingResource– Version constraints

• Hence, we cannot constrain version to VRML format in all cases

Problem Statement (2)• In just one hosting environment (OS), in just several popular OSes, we find

“version” information consisting of some combination of:– Generation– Edition– Ver– KernelVer– Maint– BuildNum– CodeName– ProdNum

• My computer’s version identification information is “Version 5.1 (Build 2600.xpsp_sp2_gdr.050301-1519:Service Pack 2)”– Windows version numbers (“5.1”) are little used– “XP” serves as a major version number, but doesn’t appear as a classic one– Build number is a key identifier, but does not update the version number– Etc. (and similarly in other OSes/hosting environments/applications…)

• Fixes (maintenance level, patches applies) are key version indicators in many OSes

Alternatives• Specify superset of known version identification mechanisms

– Generation– Edition– Ver– KernelVer– Maint– BuildNum– CodeName– ProdNum Will this cover all hosting environments?

• Map everything to VRML [’] Is this possible?

• Specify subsets per hosting environment (profile) Will this cover the full spectrum?

• Enrich current structured version information (VMRL++) How many version specifiers? Is this possible?

• Allow free-form version specification and (partially) punt Doesn’t improve the situation, weakens rigor of SDD

Regardless, SDD must provide version comparison guidance

Proposal1. Accommodate (“import”) all version specifications

• genericVersionString

2. Define sequence in schema to allow genericVersionString to be mapped to version parts for version comparison

3. Specify mapping to this structure in profiles– Manufacturer-to-SDD neutral vocabulary– Current “VRML” definition needs to be expanded to include non-

numeric characters; probably split into separate elements– Add a string for versions that can’t be structured??

4. Update version comparison algorithm to handle non-numeric values

Result is: Normalization of version information Accommodation of “all” versions with structuring for comparison

Schema[add]: <element name=“genericVersionString” type=“string”>[current]:

<simpleType name="VersionStringType"><restriction base="string">

<pattern value="([0-9]{1,9})(\.[0-9]{1,9}){1,3}" /></restriction>

</simpleType>[replace with]:

<complexType name="VersionStringType"><element name=“major"> type=“string" minoccurs=“1”/><element name=“minor"> type=“string" minoccurs=“0”/><element name=“discriminant"> type=“string"

minoccurs=“0”/><element name=“additionalDiscriminant"> type=“string"

minoccurs=“0”/></complexType>

Notes:1. How many elements needed (3? 4?)2. Should version part strings have restrictions?3. Do we need a choice for VersionStringType to allow a genericVersionString as

the other choice?

Example (1)Windows “Version 5.1 (Build

2600.xpsp_sp2_gdr.050301-1519:Service Pack 2)”

1. Accommodate (“import”) all version specifications• genericVersionString= “Version 5.1 (Build

2600.xpsp_sp2_gdr.050301-1519:Service Pack 2)”

2. Specify mapping to structure in profiles– major=“5”– minor=“1”– discriminant=“2600”– additionalDiscriminant=“”

Example (2)RHEL “RHEL AS 3 Update 8 k2.6.10-xenU”

1. Accommodate (“import”) all version specifications• genericVersionString= “RHEL AS 3 Update 8

k2.6.10-xenU” (note: K2.6.10 is kernel version, which is distinct from the Linux release)

2. Specify mapping to structure in profiles– major=“AS 3”– minor=“”– discriminant=“”– additionalDiscriminant=“”

Open Items/To-Dos1. Need to survey broader set of software

• Will everything we find map to this?• Integrate with profile generation

2. Need to incorporate genericVersionString in schema

3. Need to incorporate new version structure (versionType; the re-defined VRML) in schema– Multipart/separate elements rather than dot-separated

string– Alphanumeric, not numeric only

4. Need additional robust examples

5. Need to update version comparison algorithm