Using intergrated models

[lmichel]

I open this thread because several times in the discussion I mentioned SAMP as an interesting use-case for using integrated models and I never took room enough to tell more on this.

Let's imagine the Samp emitter showing up a VOTable where the user spots one interesting source (table row).
So far and within the limits of my SAMP skill, if that user want's to share this source (not only the position but all parameters) with other applications, he/she has to generate a single-row VOTable and operate a table.load with the hope that the recipient will be able to parse it (*)

If that Votable is mapped on MANGO, the client will be able to easily build a MANGO (source) instance serialized in a convenient way (e.g. JSON - I like it - MType=mango.load.json) that can be interpreted very easily by e.g. a web application.
This will work whatever the complexity of the source data (grouped columns, associated detection ...) thanks to the use of an integrated model. This example can be extended to other models.

This is one of the cases for which I promote the use of integrated models. This is little aside of the main topic (VOtable annotation) but anticipating new realistic usages must be part of the design.

(*) All VO client are able to parse VOTables, but Samp can be used in other contexts, (WEB applications in mind).

[msdemlei]

On Wed, May 05, 2021 at 08:53:54AM -0700, Laurent MICHEL wrote: Let's imagine the Samp emitter showing up a VOTable where the user spots one interesting source (table row). So far and within the limits of my SAMP skill, if that user want's to share this source (not only the position but all parameters) with other applications, he/she has to generate a single-row VOTable and operate a `table.load` with the hope that the recipient will be able to parse it (*)

No, what applications currently do is transmit the VOTable and send table.highlight.row (or table.select.rowList) messages. Which certainly could be improved in several ways, but I'd be reluctant to invent something entirely new unless we had a very clear scenario where what we have is insufficient beyond repair. And until then I'm afraid the somewhat hazy perspective of sending around json "instances" doesn't convince me it's a benefit proportional to the cost of having most of our data models depend on each other (not to mention I'm rather confident we could do about the same with isolated models once it's clear what exactly we'd be trying to do).

This is one of the cases for which I promote the use of integrated models. This is little aside of the main topic (VOtable annotation) but anticipating new realistic usages must be part of the design.

The trouble with anticipating without implementation is that it's almost certain to come out wrong; basically anything we've specified with "future requirements" has turned out to be a pain once the requirements actually came along (I mention caproles again because it's really worrying me). And that's no wonder: When was the last time you wrote tests and code and the tests passed the first time you ran them? And when was the last time you made a design on paper and the eventual programme bore much resemblance to that design? We're doing something even more complicated here than just writing a programme. We're writing many programmes at once. Hoping we'll get it right without having implementations along every step of the way is probably not going to turn out well. [Which is why I'm urging so much to get client writers on board]

(*) All VO client are able to parse VOTables, but Samp can be used in other contexts, (WEB applications in mind).

There *is* a VOTable parser for javascript, and maintaining that is probably less work than inventing a VOTable-in-json scheme and then writing a library for that (but that's really an entirely different topic).

[lmichel]

JSON is major transport format and checking that my model instances can be serialized in JSON is just common sense.