1. OASIS SDD TC Version Proposal Brent A. Miller STSM, IBM Corp.

2. 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 • We specify a version comparison algorithm

3. 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

4. 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

5. 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

6. Proposal • Accommodate (“import”) all version specifications • genericVersionString • Specify mapping to VRML in profiles • Manufacturer-to-SDD neutral vocabulary • a la packageType (etc.) • Add “fix” information • Maintenance level, patches • Consistent with fixInformation • Result is: • Normalization of version information • “Best” (VRML) version specification, enhanced with fix information

7. Example (1) Windows “Version 5.1 (Build 2600.xpsp_sp2_gdr.050301-1519:Service Pack 2)” • Accommodate (“import”) all version specifications • genericVersionString= “Version 5.1 (Build 2600.xpsp_sp2_gdr.050301-1519:Service Pack 2)” • Specify mapping to VRML in profiles • V=“5” • R=“1” • M=“Build 2600.xpsp_sp2_gdr.050301-1519:Service Pack 2” • L={Ø} • Add “fix” information • Maintenance Level=“Service Pack 2” • Patches={MS04-014 (837001), MS04-032 (840987), …} Ø

8. Example (2) RHEL “RHEL AS 3 Update 8 k2.6.10-xenU” • Accommodate (“import”) all version specifications • genericVersionString= “RHEL AS 3 Update 8 k2.6.10-xenU” • Specify mapping to VRML in profiles • V=“3” • R=“AS 3” • M=“k2.6.10-xenU” [kernel version] • L={Ø} • Add “fix” information • Maintenance Level=“Update 8” • Patches={Security Errata, …} Ø