RE: [security-services] versioning

[Scott Cantor <cantor.2@osu.edu>]

> I've gotten confused on versioning.

Unlike me, right. ;-)

> It seems to me that namespaces are schema versioning and the 
> major/minor message versioning is for application versioning, 
> and that one needs both. To date we've 
> often overloaded namespace to also mean semantic versioning.

I'd pretty much agree with that, but I think it's a common convention that schema versioning == namespace, as opposed to a hard and
fast rule. Namespaces predate schemas, remember, and why do they have a schema version attribute in XML Schema? So, muddy at best.

> 1. major and minor version are conveyed in the message

For a specific kind of version, something I call "message version" or perhaps sometimes "protocol version". I think it's useful to
be clear about the different versions we talk about.

> 2. when a major schema change is made the XML namespace is 
> revised as well as the major version, but when the major 
> version changes the namespace need not change if the schema 
> has not had major changes.

That sounds right to me. Technically one could consider every namespace to have its own message versioning sequence (i.e. you could
start over at 1.0 again), not that I think that's a good idea.

> Major schema changes requiring a namespace change:
> - add a required element or attribute to an existing type. 
> (regardless of whether the schema was open with any)
> - Remove an existing element or attribute
> - Redefine a simple type, other than restriction of range

Again, sounds about right.

> Although I understand the goal of minimizing schema changes 
> to support minor versioning, wouldn't a namespace change be 
> required to enable a validating parser to use the correct 
> schema to validate changes such as adding new global elements 
> or adding optional elements/attributes to existing types as well?

Not unless you assume that once you publish a schema, it has to remain frozen for all time. Many people assume that, and it may be
that commercial practices dictate that this be so in the context of something like SAML. I merely contend that's not the obvious
intent of the XML Schema specification, and XML in general. Languages evolve, IMHO, and not just by changing the name from English
to English2.

I can't argue that on behalf of the world, so I'm basically stating my opinion, that I ought to be able to plug the changed schema
into my product with a tiny patch, change no code, and become forward compatible, if I choose to do that. If I can't get away
without changing the code, then either the schema change was not forward compatible, or I have a bug. Again, that's just my opinion.

Also, if you look at the kinds of effects that adding new globals has, you'll see that there's no real difference between adding
them in the same namespace or in a new one. Either way the old code won't validate them. So why change the namespace?

A perfect example is the new SSOQuery I proposed. There's no way any existing SAML product would be expected to process that, and no
sender would expect one to, so why need it be defined in a new namespace? To change the error message?

> If a namespace is needed to validate (not always performed) 
> couldn't a receiver validate against an acceptable schema as 
> stated in a message (different messages could have different 
> namespaces),  while using major/minor message versions for 
> semantic understanding?

Sure, but...

> Thus a receiver would use the namespace to validate the 
> schema, message version (major.minor) to ensure use of the 
> correct namespaces and also to manage correct semantics. In 
> this case a namespace change might not require a major version change.

This is still a major change, as far as my definition goes. I have to change my code (a lot in some cases), there's no way my new
messages will be consumable by older code, etc.

It may not be a hard and fast requirement that minor changes be forward compatible, but I have a really hard time buying a change
that isn't as minor.

> Does it make sense to consider versions as a triple: (major, 
> minor, namespace), where multiple namespaces might be 
> appropriate for major.minor

That's pretty much where I disagree. I would put it this way:

(namespace, major, minor) where one namespace could have multiple message versions associated with it. But a given major.minor for a
particular versioned element like Assertion would have exactly one namespace for that major version.

-- Scott


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>