[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[news.eclipse.technology.kepler] Re: Versioning the models 
Thomas,

Maintaining backward compatibility is definitely the way to go if at all possible. Certainly for the models we've developed in EMF itself we've always maintained backward compatibility since generally folks expect their APIs to be binary compatible and an API corresponds quite directly to the model whether it's a schema or another expression of the same thing. In cases like UML, where the specification itself evolved in an incompatible way, they chose to change the namespace of the model and provide migration support for older serializations. There are several ways such migration can be supported. Since dynamic EMF can process an instance file given just an .ecore instance describing the model without there being any corresponding generated code, that's one possible way. I.e., read the instance using dynamic EMF and then translate it to the new model's instance. For UML2 this technique is done more on the fly by mapping the dynamic Ecore instance to the newer generated instance and then using that mapping to directly read the old instance serialization as a new instance; of course they can tell the difference between old and new by the fact that they are using different namespaces. We use a similar technique to be able to read and write Ecore as a standard EMOF serialization. Another technique that's quite useful is OPTION_RECORD_UNKNOWN_FEATURE. This effectively stashes anything that's not recognized on the side as a populated instance of AnyType, EMF's equivalent of xsd:anyType, i.e., effectively a DOM representation. This could then be post processed to convert the data. This option is useful for providing forward compatibility, i.e., the ability to read a newer serialization using an older model, because when you write the instance back out, the unrecognized data is injected back into the serialization; the order will be affected though, which might be not so good for a schema based model.


Thomas Hallgren wrote:
One, perhaps naive way, of solving the problem is to always maintain backward compatibility. It generally makes the users happy too. It's sometimes a nuisance though since you might change the semantics in a way that makes it very difficult.

A validating parser will always know the version of the schema so it should be able to cater for backward changes. Forward compatibility is another matter of course. The way we've done it in Buckminster, the old parser would simply fail with a message that the new schema cannot be found.

I have no idea how any of this works in EMF. I guess you'd have to tailor your parser to cater for differences. I doubt there's any built-in support for versioning.

- thomas


Philip Dodds wrote:
I suppose its the old question of versioning the root element or versioning the schema. I was just curious as to the impact on the parsing of versioning the schema?

Cheers

P

On 2007-08-28 06:56:54 -0400, Carlos Sanchez <carlos.sanchez@xxxxxxxxxxx> said:

if you version the model you will have to version the schema anyway,
because if you change something in the schema you don't want it to be
applied to old models

Philip Dodds wrote: 
so the schema namespace would therefore contain the version ie.
http://www.eclipse.org/kepler/project/model/1.0

So if you are using EMF how does this work - do you need to have a
different generated code for each version?  so that you can load
different versions and then "upgrade" the older versions?

Welcome back by the way ;)

Cheers

P



On 2007-08-27 13:41:22 -0400, Thomas Hallgren <thomas@xxxxxxx> said:

I think that since the model is described by a schema, the schema
should be versioned, not the model. Implies of course that any
instance of the model contains correct xmlns attributes.

Regards,
Thomas Hallgren

Philip Dodds wrote: 
I was looking at the models that we have started to add for the core
structure of the project meta-data at
http://wiki.eclipse.org/Kepler_Schema_project-core

I was thinking that we should probably add a model version attribute
to the project element and also to the facet's so that we can handle
changes in the core model in the tooling.

Thoughts ?

Cheers

P