[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita] Groups - New Action Item #0023 Embedding version numbersin cat...
Paul Grosso wrote: >>Thus, the general practice is that namespace URIs are >>invariant and do >>not include any sort of version identifier. That is, DITA is >>DITA in all its versions. > > > I certainly agree with this in principle and would > like to see us maintain this. However, if we decide > to do some renaming under the guise of "naming convention > cleanup" in DITA 2.0, we might find ourselves deciding > to bump the namespace. I agree. I was thinking about this this morning. I think one useful way to think about it (and hopefully avoid some unproductive existential discussions) is that in the context of XML applications there are two distinct domains of versioning: - Versions of applications, i.e., SGML -> XML, IBM DITA -> OASIS DITA 1 -> OASIS DITA 2, etc. Applications are identified by namespace URIs, which change only to reflect a new version of an application--otherwise they are invariant and, ideally, singular, such that for a given application there is exactly one namespace URI that normatively identifies that application. - Versions of implementation artifacts for a particular version of an application, i.e., the DITA 1.0 DTDs, the DITA 1.1 DTDs, etc. Artifacts ("files") are identified by external identifiers, resource identifiers in Web parlance. A given artifact should have at least two normative identifiers, one that is version specific and one that means "latest available version". At the level of applications, they are versioned when their core semantics change sufficiently to make the new version markedly different, and largely incompatible at the detail level, with the previous version. Of course when this occurs for a particular application is a matter of policy and preference--there is no obvious set of clear-cut tests for when an application should be considered to have evolved into a new version. Certainly syntatic changes in the implementation details are a strong argument for versioning but not necessarily conclusive. At the level of application implementations, new versions are created any time any aspect of an implementation artifact changes. This is standard storage object versioning and should not be controversial. The only question that tends to come up is when are new versions "published". This is a basic problem in configuration management and lifecycle management and is not unique to XML applications. For example, while Eric is refining a given declaration set he will create many intermediate versions of the file but only the last one he creates will be made public as "the next version" of the file. While he's doing development he's not going to change the external identifiers pointing to this revised component--it would be too disruptive to his development activity. Only after he's gotten everything working as he wants it to will he update the external identifiers, update the relevant XML catalog entries, and publish the result. Cheers, E. -- W. Eliot Kimber Professional Services Innodata Isogen 9390 Research Blvd, #410 Austin, TX 78759 (512) 372-8155 ekimber@innodata-isogen.com www.innodata-isogen.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]