MHonArc v2.5.0b2 -->
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]