W3C home > Mailing lists > Public > www-qa@w3.org > July 2004

Re: XML Extensibility and versioning

From: <david_marston@us.ibm.com>
Date: Sat, 24 Jul 2004 23:25:24 -0400
To: www-qa@w3.org
Message-ID: <OFDA535F90.2FD69F64-ON85256EDC.000FADC3-85256EDC.0012D62A@lotus.com>

DHM>XML.com published an article from Dare Obasanjo [1] yesterday, about
DHM>XML Extensibility and Versioning; I've only skimmed through it, but
DHM>it seems to touch on several of the points that SpecGL tries to
DHM>address in extension and deprecation applied to the specific case of
DHM>XML languages.

I think SpecGL has covered most of the points about extensibility. Of
note: An extensible product should be able to support multiple sets of
extension items. Another concept that this article brought out is that
the extension may itself be extensible, and that this is desirable for
XML vocabularies. For example, a vertical industry vocabulary needs to
describe payment terms and chooses to use a financial-industry XML
vocabulary for that, rather than inventing their own. The financial
industry consortium in turn chose to use a pre-existing vocabulary that
describes currencies and exchange rates. If somebody creates a good
extension to the currency/exchange vocabulary, the enclosing vocabularies
should either simply inherit it or have a mechanism to denote that parts
of the extension will be needed.

Versioning is another issue. Both [1] and the article it follows up on
[2] suggest that extensibility mechanisms can help solve the issues of
versioning. Any WG should look into the versioning problem and the TAG
deliberations on the issue(s). However, the SpecGL is currently about
good practices for *one* edition of a spec, so some of the versioning
issues have been skirted. (Not all, since it mentions deprecation.)
When reading the articles, also note that the class of product dictates
the the treatment of differently-versioned content, just as I said in
the sequencing of the DoV. This principle is most famous in HTML, with
its producer and consumer classes.

Would it be enough for SpecGL to say that every WG must assume that
there will be a newer version of every spec? Maybe we could add in some
principles that are already well established, such as: everything in the
XML world must be marked with a version identifier.

Ideally, a WG would issue a versioning plan along with (or incorporated
into) their first working draft of their version 1.0, so that interested
parties can comment on the adequacy of the plan at an early enough stage.
However, the WG may not follow that plan in the future, and the TAG or
some other representative of pan-WG wisdom may change the versioning
technology or policy before 2.0 comes out. Therefore, I think its hard
for SpecGL to get very specific about versioning.
.................David Marston

1. http://www.xml.com/pub/a/2004/07/21/design.html
2. http://www.xml.com/pub/a/2003/12/03/versioning.html
Received on Saturday, 24 July 2004 23:25:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:40:35 UTC