<div dir="ltr">(Sorry if you get this twice, I originally sent this email from my JHU account which is not registered with IVOA mailing lists)<div><p class="gmail-MsoPlainText">HI<span></span></p>
<p class="gmail-MsoPlainText">Sorry for missing early part of the discussion, was
travelling.<span></span></p>
<p class="gmail-MsoPlainText">It seems that at least it is agreed that we should
distinguish the VO-DML spec from the serialization/mapping spec.<span></span></p>
<p class="gmail-MsoPlainText">And that the issue Markus brings up is one for the latter
only, apart from possible discussions on the contents of the ivoa model, which
belongs to the RFC page?<span></span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText">> -----Original Message-----<span></span></p>
<p class="gmail-MsoPlainText">> From: <a href="mailto:dm-bounces@ivoa.net">dm-bounces@ivoa.net</a> [<a href="mailto:dm-bounces@ivoa.net">mailto:dm-bounces@ivoa.net</a>] On Behalf Of <span></span></p>
<p class="gmail-MsoPlainText">> Markus Demleitner<span></span></p>
<p class="gmail-MsoPlainText">> Sent: Wednesday, April 12, 2017 5:04 AM<span></span></p>
<p class="gmail-MsoPlainText">> To: <a href="mailto:dm@ivoa.net">dm@ivoa.net</a><span></span></p>
<p class="gmail-MsoPlainText">> Subject: Re: ivoa: DM type system<span></span></p>
<p class="gmail-MsoPlainText">> <span></span></p>
<p class="gmail-MsoPlainText">> Hi,<span></span></p>
<p class="gmail-MsoPlainText">> <span></span></p>
<p class="gmail-MsoPlainText">> On Tue, Apr 11, 2017 at 06:41:46PM +0200, Laurent
Michel wrote:<span></span></p>
<p class="gmail-MsoPlainText">> > I agree with Markus, having LITERAL @dmtypes
compliant with VOTable <span></span></p>
<p class="gmail-MsoPlainText">> > datatypes would be valuable. Unfortunately, LITERAL @dmtypes are <span></span></p>
<p class="gmail-MsoPlainText">> > not necessarily in the ivoa name space
(ivoa:xx).<span></span></p>
<p class="gmail-MsoPlainText">> > They can refer to dataTypes defined into the
model. This is the case <span></span></p>
<p class="gmail-MsoPlainText">> > for ENUM literals e.g..<span></span></p>
<p class="gmail-MsoPlainText">> <span></span></p>
<p class="gmail-MsoPlainText">> Are there any other cases except ENUMs? <span></span></p>
<p class="gmail-MsoPlainText">datetime! Any
custom primitive types some model defines. For example Mark CD has been wanting
to add a URL type as separate from anyURI).<span></span></p>
<p class="gmail-MsoPlainText">Fields outside of astronomy introduce
"zip-code" type as a string obeying certain restrictions.<span></span></p>
<p class="gmail-MsoPlainText">Similarly decimal can be seen as a rational with
denominator a power of 10. <span></span></p>
<p class="gmail-MsoPlainText">No doubt there are many others.<span></span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText">Introduction of such custom primitives is easily accommodated
in our VO-DML mechanism, where the basic primitives are explicitly defined as
types and hence can be extended. NOT as a listing of valid values as in
VOTable. My guess would be that it is because the VOTable datatypes are defined
in the schema and we're so afraid of backwards compatibility that we do still
not have a datetime datatype there?<span></span></p>
<p class="gmail-MsoPlainText">Also, VO-DML aims to be representation neutral, hence
restricts for example its numeric types to the mathematical number systems
(N,Z,Q,R,C), rather than using the software representations,
short/int/long(/longer/longest?). This is one reason why rational is included.
Also it is datetime, not date, or time, or MJD, UTC, or whatever. Again, those
are deemed to be serialization issues and it completely proper for VOTable to
define those, but no need to do so in VO-DML.<span></span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText">> If not, I'd say there's no big<span></span></p>
<p class="gmail-MsoPlainText">> incentive to introduce any complication here. <span></span></p>
<p class="gmail-MsoPlainText">> When we just use VOTable types:<span></span></p>
<p class="gmail-MsoPlainText">I hope that with "just" you mean, allow one to
use the VOTable datatypes in LITERAL? Not doing something to 'ivoa' data model?<span></span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText">> <span></span></p>
<p class="gmail-MsoPlainText">> (a) normal clients just mind that they can parse the
thing. For that, <span></span></p>
<p class="gmail-MsoPlainText">> they just need the VOTable datatype (and they
already have parsers for <span></span></p>
<p class="gmail-MsoPlainText">> that)<span></span></p>
<p class="gmail-MsoPlainText">> <span></span></p>
<p class="gmail-MsoPlainText">I expect with 'normal clients' you mean those that will
ignore the whole VODML element? If so there is no issue as only there LITERALs
will occur<span></span></p>
<p class="gmail-MsoPlainText">> (b) validators can infer the the set of allowed
values from the VO-DML <span></span></p>
<p class="gmail-MsoPlainText">> document, because the literal's role is known from
where it stands in <span></span></p>
<p class="gmail-MsoPlainText">> the instance document, and the VO-DML states what
type that role has <span></span></p>
<p class="gmail-MsoPlainText">> (i.e., in this case the allowed literals).<span></span></p>
<p class="gmail-MsoPlainText">> <span></span></p>
<p class="gmail-MsoPlainText">> -- which of course begs the question whether we
can't scupper LITERAL <span></span></p>
<p class="gmail-MsoPlainText">> again and just use PARAMs instead of them.<span></span></p>
<p class="gmail-MsoPlainText">> <span></span></p>
<p class="gmail-MsoPlainText">That was what I originally used in th rewrite of the
mapping syntax, but we (focus team)
decided, I think correctly, that we'd like to remove any dependency on VOTable
elements, something Laurent and Mark touched upon in their replies I think.<span></span></p>
<p class="gmail-MsoPlainText">Doing so makes it possible to separate the schema for
VO-DML mapping elements out from the main VOTable schema. <span></span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText">Also, it was decided that the dmtype would be mandatory
even if the type is not being cast to a more specific type than the one
declared for a Role? <span></span></p>
<p class="gmail-MsoPlainText">Would you want to remove that requirement form the
mapping?<span></span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText">> > Finally, I do not think that renaming ivoa
types as VOTable <span></span></p>
<p class="gmail-MsoPlainText">> > datatypes will help that much.<span></span></p>
<p class="gmail-MsoPlainText">> <span></span></p>
<p class="gmail-MsoPlainText">> Well, it's certainly saving clients the trouble of
having to come up <span></span></p>
<p class="gmail-MsoPlainText">> with parsers for all the literals of the VO-DML
types when they <span></span></p>
<p class="gmail-MsoPlainText">> already have parsers for the VOTable types. I'd say that's, if <span></span></p>
<p class="gmail-MsoPlainText">> nothing else, a courtesy to implementors, and given
they're the ones that eventually control takeup, that ain't so bad.<span></span></p>
<p class="gmail-MsoPlainText">> <span></span></p>
<p class="gmail-MsoPlainText">Main issue seems to be LITERAL-s and the fact that, being
standalone, one can currently not use the VOTable datatypes.<span></span></p>
<p class="gmail-MsoPlainText">One solution as you say is to use PARAM, other is to add
the VOTable datatype as an attribute to LITERAL.<span></span></p>
<p class="gmail-MsoPlainText">Both break the nice feature of 'vo-dml part is independent
of VOTable elements and hence can be separated easily and hence VOTable schema
readers who don't want to have to skip past lots of VO_MDL elements don't have
to'. This separation would also enable
us to reuse the VO-DML-only part of the mapping spec to be used outside of
VOTable contexts. <span></span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText">I presonally would prefer to *not* have to pollute the
VO-DML part this way. To me any parser interested in the VO-DML mapping worth
its salt should be able to deal with vodmlref elements, hence should be able to
parse 'ivoa:string' and should be able to translate this to a type in the
language it is coded in. And anyone not interested in the VO-DML annotation
would ignore LITERALs anyway. Yes it might be another impedance mismatch, but
one could argue that resolving those is what VO is all about.<span></span></p>
<p class="gmail-MsoPlainText">In fact, I always thought the main role of data models in
the VO would be to simplify the resolution of those impedance mismatches, both
as semantic and syntactic level. ISO having to be able to translate every
representation into every other one, O(N^2) complexity, one has a central, core
representation into and from which one needs to be able to translate these
representations, providing "only"
O(N) complexity. (See section 5 in the OLD <a href="http://wiki.ivoa.net/internal/IVOA/IvoaTheory/Theory_in_the_VO_whitepaper.pdf">http://wiki.ivoa.net/internal/IVOA/IvoaTheory/Theory_in_the_VO_whitepaper.pdf</a>
or section 2 in <a href="http://wiki.ivoa.net/internal/IVOA/IvoaDataModel/DomainModelv0.9.1.doc">http://wiki.ivoa.net/internal/IVOA/IvoaDataModel/DomainModelv0.9.1.doc</a>
proposing data models as a kind of eparanto).<span></span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText">Anyway, note also that VOTable mappers will have the
option of using a CONSTANT (i.e. the VO-DML-mapping equivalent of a PARAMref),
i.e. create a VOTable-typed PARAM somewhere and refer to it. I would definitely
NOT propose this as a solution though.<span></span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText">Cheers<span></span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText">Gerard<span></span></p>
<p class="gmail-MsoPlainText"><span> </span></p>
<p class="gmail-MsoPlainText">> --
Markus<span></span></p></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 12, 2017 at 5:04 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
On Tue, Apr 11, 2017 at 06:41:46PM +0200, Laurent Michel wrote:<br>
> I agree with Markus, having LITERAL @dmtypes compliant with VOTable<br>
> datatypes would be valuable. Unfortunately, LITERAL @dmtypes are<br>
> not necessarily in the ivoa name space (ivoa:xx).<br>
> They can refer to dataTypes defined into the model. This is the<br>
> case for ENUM literals e.g..<br>
<br>
Are there any other cases except ENUMs? If not, I'd say there's no<br>
big incentive to introduce any complication here. When we just use<br>
VOTable types:<br>
<br>
(a) normal clients just mind that they can parse the thing. For<br>
that, they just need the VOTable datatype (and they already have<br>
parsers for that)<br>
<br>
(b) validators can infer the the set of allowed values from the VO-DML<br>
document, because the literal's role is known from where it stands in the<br>
instance document, and the VO-DML states what type that role has<br>
(i.e., in this case the allowed literals).<br>
<br>
-- which of course begs the question whether we can't scupper LITERAL<br>
again and just use PARAMs instead of them.<br>
<br>
> Finally, I do not think that renaming ivoa types as VOTable<br>
> datatypes will help that much.<br>
<br>
Well, it's certainly saving clients the trouble of having to come up<br>
with parsers for all the literals of the VO-DML types when they<br>
already have parsers for the VOTable types. I'd say that's, if<br>
nothing else, a courtesy to implementors, and given they're the ones<br>
that eventually control takeup, that ain't so bad.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Markus<br>
</font></span></blockquote></div><br></div>