3rd try on versioning question

I have asked a few times, and have not quite given up just yet.  I am
looking for an industry standard on how to do versioning and
extensibility.  It would be great if there was a standard way of doing
this.  I have used some standards that kind of messed up and we couldn't
extend it.

Something new in the xsd like below would help greatly in this area.....

Say you have xml
<CarVersion1>…<CarVersion1>
The next standard comes out and is
<CarVersion2 super=”CarVersion1”>….<CarVersion2>  where they have added
subelements to the standard
And another
<CarVersion3 super=”CarVersion2:CarVersion1”>….<CarVersion3>
Last one decides it is not compatible with version 1 anymore(only stays
compatible with last 2 releases
<CarVersion4 super=”CarVersion3:CarVersion2”>….<CarVersion4>

Typically you only stay compatible 3 releases back(well, if you can even
do that as without some strategy like above in w3c specs, it is really
hard to do such a think).

Now, if I have a server that sends back CarVersion3 events, a client who
only knows version 1 can understand the event as he will ignore all the
fields in the sort of a subclass kind of thing.

Instead, all companies I know of implement a version 3 spec and send back
version 1, version 2, version 3 events resulting in 3 times the code. 
This is not pretty.  Is there a cleaner way I am not aware of?

This also solves the extensibility problem allowing companyX to create
<CompanyXCar super="CarVersion2:CarVersion1">...

Notice that the parser can look at CompanyXCar and if it only knows the
version 1 spec, will automatically know that this is CarVersion1.  The
super is a list of elements that this xml packet also happens to be.

This also helps with SOAP alot because objects can be subclassed and I can
passback a subclass which will marshal to CarVersion3 instead of the
superclass CarVersion 1.  unmarshalling back will depend on the version of
the client.
thanks for any info,
dean