Philip,
EMF 2.4 will support content types that will allow you to process a bit
of the start of the resource to determine what type of resource it is.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=191077
The support is fully prototyped via the attached patch and passed all
our JUnit tests. I hope to commit it soon. It will allow you to
associate a content type identifier with a namespace and then register
a resource factory based on that content type. So it would be possible
to use the same file extension for both old and new files but to
register different resource factories to handle them. Of course you
could do this same kind of differentiation from within a single
resource implementation.
Philip Dodds wrote:
Ed,
Thanks for the insight - Backward compatibility is the way to go but
looks like the best way going forward it to wrap EMF configuration
reading activities in a parser that uses the dynamic EMF reader to work
out what version of the model is being stored and then use that to
determine if there is anything that needs doing (I suppose the minimum
for an editor is simply reflecting the change in the schema location to
the newer version - after confirming this is what the user wants to
do).
Thanks again
P
On 2007-08-29 08:15:37 -0400, Ed Merks <merks@xxxxxxxxxx> said:
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
|