Utypes Tiger Team, Minutes of 2013-04-02 telecon

Present: Omar, Gerard, Mireille, Pat, Matthew, Jesus, Markus (minutes)

What do we want to write?

GL: Do we want one document or two (one on VO-DML, one on utypes/VOTable serialization)?

OL: Well, the second document could be "plain and simple" utype syntax.

MD: I'd somewhat prefer one document since that would better reflect our mandate.

GL: The VO-DML doc can be used without utypes, so two docs is better.

OL: If you need both documents to make sense of the whole thing, one would work. However, if we have one simple utypes document, that might be easier to sell.

MG: Yes, a "simple document" referring to a more technical one will be preferable for the exec.

GL: But what would then be in this "simple" document? There already are two documents, one being the VO-DML definition, the other the VOTable mapping, and both are not simple so far.

MG: Maybe the simple document can be an executive summary of the VOTable mapping?

OL: Would like to seperate utype syntax from the VOTable mapping, at least if utypes are parseable.

Tentative working titles for our two papers:

VO-DML: a consistent modelling language for IVOA data models (reference implemenatations: PhotDMv1-1 and SimDM)

utypes: portable data model references

path utype options

The chapter references are to https://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/VO-DML_and_UTYPE%20and%20VOTable-v0.2.pdf as of 2013-04-02.

GL: Also check 7.1 for ways to come up with utypes.

MD: We don't need a generative grammar for utypes if we just give an interpretation rule. This dodges lots of problems (e.g., possibly infinite languages with looops, etc) and solves what we want, going from utypes to VO-DML elements.

GL: Do the 7.2.x chapters in Gerard's document roughly reflect the views of the persons they're attributed to?

MD: Yes on 7.2.1.

ML: 7.2.3. is mainly ok, but we've not explored the special cases so far. One good point about this is that this lets us care for backward compatibility.

JS: 7.2.2 is mostly fine with me.

MD: We're going to break things anyway, so backwards compatibility should be an issue, but not at any price. And I don't think we can have any spec that says there are two different sorts of utypes.

OL: We should be able to map old DMs to VO-DML

GL: We can allow special protocols to define their own custom uses of utypes. Oh: Has anyone thought the various options through, enough to be able to pass an informed decision?

Several: Not me.

MD: Well, I could live with 7.2.1 and pure utypes. Everything else is building two complex and ugly edifices instead of just one that would in all likelihood suffice as well.

ML: There will be a long time until all services are upgraded to whatever we come up with now. What do we do in the meantime?

Discussion on 7.2.2: Trouble or benefit is: multiple legacy utypes would map to a single new utype/VO-DML element; some think that's great, others think it's terrible.

OL: The only objection I have to 7.2.2 is that it's less efficient. So this might be a reasonable compromise.

MD: An example would help me make up my mind.

Action item:

Everyone should write a mail saying which of pure an 7.2.x we find acceptable and/or preferable.