Discussed the finally accepted approach:
The mapping specification we'll propose will only deal with "pure utypes" approach.
Backwards compatibility is to state that existing usage can continue, but is not covered by spec.
Standards that use utypes in some manner not covered by spec remain valid (e.g. SSA),
but new versions should use the approach that we'll propose.

Custom usage can remain being used:
PD: if a GROUP with utype="vo-dml:Model" is encountered, the spec is assumed.
If not, the VOTable is not covered by the spec.
MD: utypes on FIELD, TABLE and standalone PARAM is ignored, not part of spec, hence may remain in use.
STC in VOTable is treated similalrly, will be legal (even though it has utype on GROUP)
PD: same for photometry markup note?
All: no, should be rewritten to follow new appraoch.
JS: PhotDMv1-1 will have VO-DML representation and SVO, who has been using this,
are willing to conform to our results.
MD: so now we will ignore utype on FIELD etc, how in future?
PD: users can use utypes on non-standardized elements for application specific purposes.
OL: ML and PF not here, should be polled. ML seemed worried about approach.
MG: do not need unanimity.

PD: don't like '+' based concatenation of role and type in utype.
All agree.
GL: need some solution if we want to allow type casting.
MD: suggests alternative. generally type casting is useful/relevant "only" on child GROUP-s.
these could get an extra PARAM with a dedicated utype (GL: something like vo-dml:Type.utype)
and with value the utype of the actual type.
GL: could also work on FIELDref, to indicate that different rows in a TABLE might hold different
types.

Intermezzo: Note that this means that FIELDref-s and PARAM(ref)-s can NOT use type casting.
May not seem bad as less likely to be important, but should be addressed.

PD: if we'd need changes to VOTable to make our spec work, this would look bad.
Hence against for example requesting 'urole' attribute etc.
OL: conclude: we have concensus on this approach of all participants in the current telecon.
Next, what documents will we write? These must be available ~2 weeks before interop. I.e. May 1.
MG: need not be polished.
GL: propose separate VO-DML and mapping specs. First can be used by DMs without
having to worry about the mapping issue. It is also quite far advanced, being an
evolution of VO-URP. A schema exists, a WD is in the make. Proof of concept models exists
(SimDM and PhotDMv1-1 in the make). First draft translations exist in <volute>/vo-dml/models.
Validation code exists.
Second should be evolved from the mapping document.
OL: who:
GL: volunteer to write vo-dml, insist Laurent Bourges is co-author.
Second, suggest OL (+ML) make second iteration, redacting the existing mapping doc.
GL assists (3 editors).

PD: question about FITS. We'll propose wrapping with VOTable?
All ok.
MD: can put the VOTable inside the FITS doc, in an extension, as a char array.
GL: Does datalink have anything to say here?
GL: TAP_SCHEMA could be handled similarly, a VOTable representing the complete schema.
MD: VODataService has utypes on columns as well.
all agreed to punt this issue.

Next meeting Tue 2013-04-16
PD: need at least tables of contents for the docs.
OL: any auxiliary material?
GL: models in VO-MDL.
OL: let's go.

<!--
* Set ALLOWTOPICRENAME = TWikiAdminGroup
-->