absent: Mireille (ML), Pierre (PF) MD Clarification of the tasks we are charge to produce OL There is an email from Severin GL reads the email description OL Regarding VO/DML, the final solution propoased is very close to Sebastian approach on catalogs MD we are doing something a little bit different GL simdm was accepted MG solution not accepted by all the institutions GL not clear that it is not acceptable MG PF says no ML is more balanced GL A particular VOTable can still be done as before OL We actually tried to minimize the transition from one model to the other. GL We do not say current use cannot be used MD Solid foundation in the presentation to Exec GL ML wants to have the semantics in the utype itself and not into the FIELFRef OL Parsing the utypes with support for collections and references could be also used GL It would be harder to do it that groups (in case all the support for collections & references is fullfilled) MG As as summary, the problem is that we are missing the semantics meaning in the utypes MD We should put more about SED and SpectralDM in the usages section. I volunteer myself OL We should probably divide the work as we are charge to solve the utypes syntax MG We are trying to do that with the division in two documents MD These two documents are correlated and we cannot write one without reference to the other OL One objection, we did not have the mandate to create the DM framework GL We cannot disantagle utypes and the expresion in VOTable. If utypes are not xpath expressions but pointers. We are asuming the Data modeling framework GL We are not sure if path expressions can be valid in other use cases JS in favour of a backwards compatible approach GL we do not say it is not still valid the old utypes use GL not semantics associated to path expressions JS described approach (using path utypes as aliases into VOTable fields). Alias table is not a simple table but path utypes associated to groups OL there is not a uniform standard for utypes syntax (eg. aladin brackets) JS sebastien proposal is more like the approach I propose (vo/dml with path utypes) OL not really that. Not real VO/DML. He stopped at first group level MD we should concentrate on the documents skeleton GL VO/DML first version is on volute (two different versions) and ML/OL on charge of second review of utypes doc MG Usage document will contain also the analysis MD IRIS has already part of this analysis OL if the starting point is you can use GL DM translation into VO/DML Global discussion on the edition of utypes mapping document. Parallel teleconf proposed with GL, OL, ML and JS |