I've just added Specification-Title, Specification-Version, Specification-Vendor, Implementation-Title, Implementation-Version, and Implementation-Vendor attributes to the manifest file for XOM. It's the Implementation-Version and Specification-Version that concern me. Currently they look like this:
Specification-Version: 1.0b7
Implementation-Version: 1.0b7Eventually I expect they'll look like this:
Specification-Version: 1.0
Implementation-Version: 1.0And then this:
Specification-Version: 1.0.1
Implementation-Version: 1.0.1The concern is that according to the JAR file specification only the middle one is legal. The production for version number is
version-number : digit+{.digit+}*
Thus 1.0, 1.1, and 1.2 are all legal version numbers but 1.0a1, 1.0b7, 1.0.1, 1.2.2,and so forth are not. On further research, it looks like the JAR file spec is wrong. According to the versioning specification, version numbers have the form "major.minor.micro; major version numbers identify significant functional changes, minor version numbers identify smaller extensions to the functionality, micro versions are even finer grained versions. These version numbers are ordered with larger numbers specifying additions to the specification." However, this still leaves open the question of versions like 1.0d25, 1.0a1, 1.0b7, 1.0rc1, and so forth. Further reading in the versioning spec shows that implementation versions are only compared for equality, so alphanumeric values should be OK there. However, the specification version is still an open question. Does anyone know whether using non-numeric version numbers for Specification-Version is likely to be a real problem? If so, please drop me a line.
Is anyone else as annoyed as I am by all the URLs in Sun tutorials and documentation that point into old, obsolete versions of documents that Sun has removed? Sun's Norm Walsh sits on the W3C Technical Architecture Group and Sun's Tim Bray did until quite recently, but I guess they haven't told the rest of the company about the architectural principle that "cool URIs don't change" and "A URI owner SHOULD provide representations of the identified resource consistently and predictably."