Re: Version numbers on XMLschemata

Hi Ray,

if policy is to allow small changes to the schema then I'll have to live with it. Personally, I don't like any substantive change. My personal list of acceptable changes is

1. comments;
2. schemaLocation attributes;
3. annotation;
4. formatting of XML source.

I'm not keen on "backward-compatible" changes because I always distrust the compatibilty, especially with respect to Java-binding tools.

For the record, the 2-week breakage I referred to was an AstroGrid internal error, not something caused by Registry-WG. Somebody "fixed" an error in drafting VOResource-0.10 (xsd:date "fixed" to xsd:dateTime) which looks good but actually means that there were two, incompatible versions of the IVOA schema in play. Our documents written according to the "fixed" one became invalid w.r.t the official one. When we added validation to our software, the software broke.

The same problem could happen any time a later, offical version of a schema tightens restrictions and requirements. The late change to VOResource 1.0 ("version 1.02") was one of these: it made the status attribute compulsory. It could have broken existing instance-documents. In fact, we didn't have any VOResource-1.0 documents in production, so it wasn't a problem.

I guess it comes down to whether a schema is official published or not: fluid util published, frozen afterwards. That's why Kevin and I were asking whether VOResource-1.0 was published yet. Can we, in future, be clear about which exposed schemata are fluid and which are likely to change (e.g. a comment in the schema text)?

I understand now how you use the version attribute. Seems fine to me.

Cheers,
Guy

On Tue, 21 Nov 2006, Ray Plante wrote:

> Hey Guy,
>
> On Tue, 21 Nov 2006, Guy Rixon wrote:
> > Can we _please_ not reuse XML namespaces with different content?
>
> First of all, I *completely* agree with this request--well, mostly I
> guess. Adding support for a new schema (i.e. with a new namespace) is not
> trivial for our applications; so care has to be taken. Here are the
> conditions under which I've updated the schema files but not update the
> corresponding versions
>
> 1. changes only in documentation or formatting (e.g. spacing)
> 2. backward compatible changes that should not invalidate/break
> existing instances or applications
> 3. *minor* bug fixes that
> o correct the schema to be consistant with what we been operating
> (because that's what we agreed to), and
> o is not likely to invalidate the majority of existing instances
> or applications.
>
> With the corrections I made after Moscow, all of the files except
> VOResource-v1.0.xsd fell into category 1. The changes to
> VOResource-v1.0.xsd, I believe, fell into categories 2 and 3. Now I may
> have gotten this wrong in this case.
>
> I use the version attribute as a way to connect it with a version of the
> standards document that defines it. I try to adhere to the practice of
> using the 3rd integer in the version to denote backward compatible changes
> that do not require a change in the namespace.
>
> > Changing a schema and keeping the same namespace is way too disruptive.
> > If many instance documents get out using different interpretations of the
> > namespace it's downright tragic.
>
> Changing the namespace in the context of registries--where we all have to
> use the same version for the critical schemas--is also extremely
> disruptive. That's why I feel we need this middle ground. Nevertheless,
> even if we don't think apps will break, we do need to announce even the
> minor changes.
>
> If a change has a real effect on how our applications run, then--yes--we
> need to change the namespace.
>
> > As Wil O'Mullane pointed out a while ago, vesion numbers are cheap and any
> > time that we revise an exposed (= visible on web-site) artifact we ought to
> > increment its version.
>
> They are not cheap in the IVOA! While the IVOA versioning rules are not
> suppose to apply to XML schemas, they will in practice if we define
> standard documents that define the schemas and their meaning. The rules,
> then, impose a viscosity on the advancing of versions.
>
> If you found that the changes did actually break things, I'd like to hear
> about it.
>
> Sorry for the confusion,
> Ray
>
>
>
>
>
> >
> > Cheers,
> > Guy
> >
> > Guy Rixon gtr-at-ast.cam.ac.uk
> > Institute of Astronomy Tel: +44-1223-337542
> > Madingley Road, Cambridge, UK, CB3 0HA Fax: +44-1223-337523
> >
>

Guy Rixon 				        gtr-at-ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523