OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[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]