Impact on the model change

[lmichel]

This imporant issue comes in continuation of MANGO Annotation Scope.

It continues the discussion whose content is recalled here:

have to be mapped. The rest can (must) be ignored. The mapping
block represents a subset of the model. If the model changes keep
the backward compatibility, the 'old' annotations remain consistant
and the interoperability between dataset mapped with different DM
versions is preserved.

Yes -- that's a minor version. These aren't a (large) problem, and
indeed I'm claiming that our system needs to be built in a way that
clients don't even notice minor versions unless they really want to
(which, I think, so far is true for all proposals).

If you are saying that clients must be updated to take advantage of
new model features, you are right, whatever the annotation scheme
is, this is just because. new model class => new role => new processing.

No, that is not my point. My point is what happens in a major
version change. When DM includes Coord and Coord includes Meas and
you now need to change Meas incompatibly ("major version), going to
Meas2 with entangled DMs will require new Coord2 and a DM2 models,
even it nothing changes in them, simply to update the types of the
references -- which are breaking changes.

With the simple, stand-alone models, you just add a Meas2 annotation,
and Coord and DM remain as they are. In an ideal world, once all
clients are updated, we phase out the legacy Meas annotation. The
reality is of course going to be uglier, but still feasible, in
contrast to having to re-do all DM standards when we need to re-do
Meas).

[lmichel]

I very concerned by the question of the model changes. But I cannot figure out how a class describing a measure could be upgraded in a way that breaks the backward compatiblity.

Do you have some example?

[msdemlei]

On Wed, Mar 24, 2021 at 08:16:55AM -0700, Laurent MICHEL wrote: I very concerned by the question of the model changes. But I cannot figure out how a class describing a measure could be upgraded in a way that breaks the backward compatiblity. Do you have some example?

Right now, Meas depends on on Coords, and given that that hasn't seen a lot of real-world usage, I'm rather sure we *will* want to fix things because they're just too clumsy. For instance, I suspect everyone will want time0 to just be a JD, and nobody will get it right if the offset and the value are in different frames (but that's really just an example, don't get hung up on this particular example too much). If we change time0 to a float, that's a breaking change, and that would then take Meas with it because it references Coords. I give you in that particular instance, we could fudge it by just adding a time0float attribute and tell people to not use time0, and we'd get away with it, but that's one more wart I'll have to apologise for when trying to get people to take up our standards. Planning on accumulating hacks like that is something I'd really try to avoid as long as there's an alternative that, for all I can tell, will work at least as well for the plausible use cases. More generally: The assumption that we've gotten something right that has by and large not been consumed in practice seems dangerous to me. I'm saying that as someone who's been trying to fix things that turned out wrong in Registry (which, mind you, has been a surprisingly robust design). I'm mentioning rights in VOResource and, in particular, the whole caproles mess (https://ivoa.net/documents/caproles/).

[lmichel]

I cannot imagine a int -> real cast breaking anything. All clients are able do deal with this.
I remember an old discusssion about data typing in models and sometime I regret the absence of a number type in VODML.

I tried to figure out different situations where model changes would be be letal.

1. Inapropriate downcasting (e.g. string -> numeric)
2. Splitting classes (stupid e.g. use one object from RA and another for DEC instead on one for [RA,DEC])
3. Merging classes (Coords attributes moved to Measure class)
4. Removing things (no more link between CoordSys and CoordFrame)
5. Renaming things (long -> longitude)

In the real life none is a real threat. The analogy with caprole must be carefully handle because our models are talking about physical quantities observed in the sky and caprole are talking about computer protocols that are completely abstract and flexible things.

Considering the worst, all of these cases would break the interoperability which represents a seriouser issue than encompassing model versionning:

• Data providers have to revise their annotation procedures
• Client code have to deal with the new version and even worse, manage the cohabitation of both versions.

I would even say that having encompassing model is safer, since the upgrade process garanties that all components still can work together both structuraly and semanticaly.

[msdemlei]

On Fri, Mar 26, 2021 at 04:14:12AM -0700, Laurent MICHEL wrote: I cannot imagine a *int -> real* cast breaking anything. All clients are able do deal with this.

The time0-thing would be a change from a complex time instance to just a real, so that *would* hurt.

1. Inapropriate downcasting (e.g. string -> numeric) 2. Splitting classes (stupid e.g. use one object from RA and another for DEC instead on one for [RA,DEC]) 3. Merging classes (Coords attributes moved to Measure class) 4. Removing things (no more link between CoordSys and CoordFrame) 5. Renaming things (long -> longitude) In the real life none is a real threat. The analogy with *caprole* must be carefully handle because our models are talking about physical quantities observed in the sky and caprole are talking about computer protocols that are completely abstract and flexible things.

Well, our *models* are just as flexible, and indeed going from STC1 to STC2 to MCT we've already seen two breaking changes (and, actually, many more in between). So, frankly, I don't buy the reasoning.

Considering the worst, all of these cases would break the interoperability which represents a seriouser issue than encompassing model versionning: - Data providers have to revise their annotation procedures - Client code have to deal with the new version and even worse, manage the cohabitation of both versions.

That's the flag day that I claim non-entangled models will prevent: Data providers have years or decades to migrate -- and most of their annotations won't even have to change, as they are unaffected from other model's version changes. Clients can easily pick the most appropriate annotation they can deal with; this why the use case https://github.com/msdemlei/astropy#choosing-the-most-expressive-annotation is something I'd really like to see canonised...

[Bonnarel]

My 2 cents on this. What kind of situation can we imagine for a model change ? Where does it has impact when we are considering data transport using VOTable ?

Why is one (or several) of the models changing ? I can imagine two reasons:
- The model doesn't allow an optimal interpretation of the existing transported data. A change in one (several) of the models will allow data providers to annotate better their data and clients to do better handling. The existing data tablkes don't change. Only the "separeted-from-data" annotation changes. I think it's probably possible to have two different annotation structures for clients who didn't make the evolution to remain working as before.
- Data providers make a major change in their data release which happens to be difficult to work out with current datamodel versions and is anyway an intrinsic issue for clients. In that cas a change in the models and in the annotation will be an help for evolution of the client software.
- The key thing is the independance of the annotation and of the data.

[lmichel]

going from STC1 to STC2

Good example, I guess you agree on that the major concern about moving from STC1 to MCT is not the update of the host models (that do not exist any way). This is my point.
Let's imagine that I've e.g. a model named lm_dm_1 that embeds stc1.13, Char_1 and dataset_1.5
Now stc1.13 has been moved to stc2:
In consequence I've to update my model to lm_dm_2 (stc2, Char_1 , dataset_1.5).
My points are

1. upgrading lm_dm is not big deal
2. using lm_dm_2 might be safer than using individual (stc2, Char_1 , dataset_1.5) instances since this guaranties that all three models are compliant each to other (e,g. vocabulary mismatches).
3. last but mot least: lm_dm (1 or 2) keeps giving a complete description of the modeled objects (e.g. Cubes) out of the scope of any particular data container. I know you deny this requirement, but I insist to claim that this the interoperability key.

[msdemlei]

On Wed, Mar 31, 2021 at 02:05:18AM -0700, Bonnarel wrote: My 2 cents on this. What kind of situation can we imagine for a model change ? Where does it has impact when we are considering data transport using VOTable ? Why is one (or several) of the models changing ? I can imagine two reasons:

Well, the most common reason is: we simply did it wrong. As someone who did it wrong several times already, I think I'm entitled do say that. To mention my worst goof: Using ParamHTTP interfaces in TAPRegExt, which blew up badly more than half a decade later ("caproles"). It happened because I hadn't understood the full problem, didn't see the long-term consequences, and generally shunned the work of defining an extra type for TAP-like interfaces. You *could* say other people are less lazy, think deeper, and see farther, and they probably do. But who knows, perhaps one day I'll make a DM, and then it'd be reassuring to know that if I get it as wrong as the interfaces in TAPRegExt, the VO can shed by mistake without taking the whole DM system with it.

- The key thing is the independance of the annotation and of the data.

Could you explain this a bit more? Do you mean lexical independence (e.g., annotation sits in an element of its own rather than, say, in FIELD's utype attributes)? Or semantic independence (in which case you'd have to explain how that should work)? Or yet something else? To me, I'd say the annotation depends strongly, and ideally "injectively" on the data's structure (i.e., different structures will have different annotations) and not at all on the data (which rules out follies like having pieces of photometry metadata in column values). Conversely, data and data structure do not depend at all on the annotation (which is less obvious than it may sound, but it in partiuclar means that you can attach as many different annotations to data structures as you like).

[msdemlei]

On Wed, Mar 31, 2021 at 07:05:13AM -0700, Laurent MICHEL wrote: > going from STC1 to STC2 Good example, I guess you agree on that the major concern about moving from STC1 to MCT is not the update of the host models (that do not exist any way). This is my point.

Not sure what "host model" means, but certainly no STC1 client will understand any STC2, even if we had an annotation scheme covering both (and, frankly, I think a really good STC model would deviate even further from STC1 than current Coords, but that's another matter).

Let's imagine that I've e.g. a model named `lm_dm_1` that embeds `stc1.13`, `Char_1` and `dataset_1.5` Now `stc1.13` has been moved to `stc2`: In consequence I've to update my model to `lm_dm_2` (`stc2`, `Char_1` , `dataset_1.5`). My points are 1. upgrading `lm_dm` is not big deal

Not for you as the model author, of course. But for all of your clients. Which break, and cannot read/find Char_1 and dataset_1.5 metadata any more, although they'd be perfectly capable of understanding what's in there if it weren't for the changed container. True, perhaps updating them would again be no big deal. Except that the client code still needs to be maintained and released and, most difficult of all, distributed. All of which *are* big deals in practice in a huge and diverse system like the VO. This kind of, if you will, wanton destruction of existing and perfectly maintainable functionality is what I think most of this discussion is (or ought to be) about.

2. using `lm_dm_2` might be safer than using individual (`stc2`, `Char_1` , `dataset_1.5`) instances since this guaranties that all three models are compliant each to other (e,g. vocabulary mismatches).

Umm -- could you be a bit more specific here? What annotation in a non-entangled Char_1 could possibly break when you change stc? And since you're mentioning vocablaries, given we're in RFC for that I'd be particularly interested in your concerns about their interaction with DMs and their mutual compatibility.

3. last but mot least: `lm_dm` (1 or 2) keeps giving a complete description of the modeled objects (e.g. Cubes) out of the scope of any particular data container. I know you deny this requirement, but I insist to claim that this the interoperability key.

Perhaps this is a point we'll have to discuss interactively, because I can't help feeling it's obvious that it's the other way round: If you kill all DM annotations for all existing clients if you just change a single DM incompatibly, that's then end of interoperability as soon as evolution sets in. Sure, you can hope that models won't evolve, or you can hope that by that time all you have to replace are a few wep apps on AstroBook (TM) and hence you don't need iteroperability in the first place -- but both of these I'd consider rather undesirable.

[mcdittmar]

On this topic, I'm finding myself agreeing more with Markus. (ack!)
To a certain level anyway, as I agree with Laurent's assertion 3 in this comment

Models are going to change, I think that's pretty much a given.

• as we fold in new products (Mango, TimeSeries, SED)
• broaden usage domains. eg: Radio or Planetary needs different Target type than we have spec'd in Dataset
• or just forgot something: "Spectrum doesn't support Echelle Spectra".

VODML compliant models import specific versions of their dependencies

• to make new features available under the parent models will require an update to the model (VODML/XML).

This is true, whether a major version or minor version change.

What is the impact?

• At the rate we are cranking out models in the VO, I don't think this is going to be a burden
• At the rate we SHOULD be cranking out models in the VO, this could be annoying. This annoyance may be mostly on our side, updating the VODML/XML for the model hierarchy just to change the dependency.
• Operationally a model namespace is constant for minor version changes, so users should only be impacted when a major version change is made.
  • Impact on clients/providers should be marginal. IF they want to produce/use the newer version content, they make the appropriate changes (if any, other than recognizing the new namespace) and are done. This is needed even to handle new content in minor version changes to the models.
  • Most changes would be contained to the parser/writer level, not to the classes/objects the implementations convert them to. eg: the parser package I'm using (rama) will produce an AstroPy SkyCoord for any version of meas:Point. No change to the application using it is required.
  • If they are integrating a major version change, then they should expect to be updating their implementation.

I don't think decoupling the models makes this go away:

• If a client reads Cube/Mango instances, and there is a change to Meas model, and they want to use/produce the new Meas content, is it any easier to test/verify
  1. Mango-vA with (Meas-vA or Meas-vB) content instead of
  2. (Mango-v1 with Meas-v1) or (Mango-vB with Meas-vB)

Where it DOES have a big impact is on the annotation. This is probably a good case to mock-up (since we don't have multiple versions of any models) and annotate.
With the current model/annotation relations, I believe the client would need to:

• Annotate 2 versions of the parent model objects (Source/SparseCube) to accommodate the 2 flavors of Measurement leaves.
  • looking at Standard_Properties and TimeSeries examples (Mapping syntax and ModelInstanceInVot syntax)
    • ~100:150 lines of annotation for Source instance with 5 Properties; includes 13:25 per Measure
    • ~85:140 lines of annotation for SparseCube with tiny Dataset + 3 Observables; includes 7:10 per Measure (no errors)

If decoupled

• Can annotate 1 version of parent model, and EITHER version of Measure at the leaves.
  • adding no additional annotation lines
• Or in some way allow annotation of BOTH versions of Measure at leaves.
  • adding 7:25 additional lines of annotation per Measure that has multiple versions.

If we are considering the case I'm currently working, Master(Source) with associated Detections(Source) and associated LightCurve(SparseCube), this could add up to serious real estate.

Up to now, I've considered all this "The cost of doing business.", and am comfortable with that position.
But, after seeing the ModelInstance in Mango, maybe this needs more serious consideration. I had an idea this morning, inspired by this, which may be a good compromise. It could allow looser coupling of models, but still have definitive links between them for verification/interoperability. (ie: no ivoa:anyType stuff). Once I've thought that through a bit, I'll post it in a new thread.

[lmichel]

[@msdemlei] And since you're mentioning vocablaries, given we're in RFC for that
I'd be particularly interested in your concerns about their
interaction with DMs and their mutual compatibility.

Message understood....
... but for the immediate time, the discussion is rather focused on DM concept itself.

Perhaps this is a point we'll have to discuss interactively..

Sure .I'm unable to connect the existence of Cube with the disaster that you announce

[lmichel]

I'm in line with the @mcdittmar's summary.

I've would just remind that we are talking about modeling physical entities.
The comparison with what's happened with protocols (e.g. caprole) must considered with a lot of care.

My expectation is that the introduction of new players (e.g. radio) won't break existing stuff but introduce new patterns.

• e.g. Radio dish FoVs seem a bit more complex that simple cones.
• Description of complex object shapes (clouds)
• Description of multi-object systems

I'm pretty sure that changes on model components in a way that breaks backward compatibility (no example to give) won't be endorsed by data providers or client developers either.

Let's imagine that it happens anyway,

• Data provider will have to annotate with both versions until all clients supports them (will likely never occur)
• Clients will have to support both versions as soon as a one data provider use the new version (will likely occur).

This bad situation would take place whether with the @msdemlei scheme, the @mcdittmar's one or mine.
As I said some posts ago, generating e.g. a new CUBE VODML/XML won't the major difficulty to sort this case out.

[mcdittmar]

I'm in line with the @mcdittmar's summary.
Yay! I always like hearing that!

My expectation is that the introduction of new players (e.g. radio) won't break existing stuff but introduce new patterns.

• e.g. Radio dish FoVs seem a bit more complex that simple cones.

I think the most likely breaks will come from us having concrete objects defined in a model which we later find needs to be abstract in order to support branching by different domains. It is the main reason I have elements like the abstract Uncertainty type in the Measurements model.. to help guard against major version change. I grudgingly removed the abstract Point from Coords on the last iteration, and with this Mango work, we're finding an interest in restoring the space-centric LonLatPoint/SphericalPoint. This would be a major version update in Coords.

• Data provider will have to annotate with both versions until all clients supports them (will likely never occur)
• Clients will have to support both versions as soon as a one data provider use the new version (will likely occur).
  I was thinking about this, and it seems more likely (no evidence) that the clients would prefer to output as V1 OR V2 at the user's request, rather than annotating to both in the same output.

[lmichel]

I agree that the condition for the risk (as pointed by @msdemlei) of breaking models with new features to be very low is that models have abstract classes. i.e. things that can be extended without altering existing stuff.

MANGO showed up (too much apparently) the ability of extending MCT without breaking anything.