OASIS SDD TC Version Proposal Draft 2 after Jan F2F Brent A. Miller STSM, IBM Corp.

Current State schemaVersion: –We control this –This is done  versionStringType: –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 :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

Proposal 1.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]: [current]: [replace with]: type=“string" minoccurs=“1”/> type=“string" minoccurs=“0”/> 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 :Service Pack 2)” 1.Accommodate (“import”) all version specifications genericVersionString= “Version 5.1 (Build 2600.xpsp_sp2_gdr :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 k xenU” 1.Accommodate (“import”) all version specifications genericVersionString= “RHEL AS 3 Update 8 k xenU” (note: K 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-Dos 1.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