<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Markus, All,<br> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">
<br>
</span>Well, I've put it there, and as regards pulling the ivoa data model<br>
out of VO-DML proper, I think there still is a point. Keeping what<br>
it specifies fluid until we have actual experience how these things<br>
work out while fundamental things like stc and whatever we use to<br>
model value+error are in flux would seem wise to me.<br></blockquote><div><br></div><div>Hear, hear. Shall we do it? <br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">
</span>I feared it would come to this. After long contortions, we<br>
eventually reached agreement on using<br>
<br>
datatype="char", arraysize="*", xtype="timestamp"<br>
<br>
in DALI, sect. 3.3.3, for these.<br></blockquote><div> </div><div>If I am not mistaken the schema says xtype is a string (more specifically an xs:token) while datatype is restricted to a bunch of strings.<br><br></div><div>You then need three pieces of information (datatype, arraysize, and xtype) to express that something is a timestamp, but that's just because the schema mandates datatype (and in this case arraysize to be present) because otherwise xtype (and maybe even ucd) would be enough for the semantics. For a lot of code out there that doesn't parse xtype, the datatype and arraysize are also enough to figure out the content is a string (not a number or a boolean), and treat it as such.<br><br></div><div>I believe there could be value in keeping the votable datatypes in the mapping syntax for the reasons you explained, yet the existence and usage of xtype demonstrates that you need more semantics in some cases.<br></div><div><br></div><div>In the current mapping draft (I hope we can get an announcement early next week, I have been pushing for announcing the draft for a while) you have two xml types that refer to FIELDs and to PARAMs. For these elements I wouldn't mandate anything other than the vodml type (currently called dmtype, more on this below). The datatype and maybe xtype will be in the elements being referenced.<br><br></div><div>As mentioned, the problem is just with LITERAL. The compromise that comes to mind is to provide LITERAL with votable-like datatype and arraysize attributes. [although for the reasons Gerard mentioned I would keep them separate from the current VOTable types so we can keep the schemata distinct... that's a second order detail, though].<br><br></div><div>One could then use the currently defined xtypes to come up with a core of ivoa types. The problem here is that the vodml type descriptor needs to be a vodmlref, i.e. an ns:type kind of string, which "timestamp" and the like are not. So timestamp would need to become ivoa:timestamp.<br></div><div>Another option would be to define an xtype model with a bunch of vodml primitive types, so you would have xtype:timestamp. Again, second order detail, the point being that you need a qualified name for the dmtype attribute.<br></div><div><span class="gmail-"></span><br>Another option might be to explicitly map ivoa primtitive types to xtype
definitions (I guess there are also some VODML DataTypes, e.g.
xtype="point"), e.g. ivoa:datetime -> xtype=timestamp (are they truly
the same, though?) and votable datatype's, e.g. ivoa:string ->
datatype="char", arraysize="*". For ivoa primitive types this could be
done in the mapping document itself, for more complex stuff like
xtype="point" this can only be done once the relevant model is
standardized, e.g. STC. It's then less clear where the additional
mappings like xtype="point" -> dmtype="stc2:Coordinate.Point" (I am
making this up right now) should go.<br></div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<br>
But if the price for this is that people, within one VOTable, have to<br>
recognise timestamps in LITERALs by seeing it's<br>
vodml-type="ivoa:datetime" and using one literal parser, while having<br>
to check xtype and use a different literal parser when it's in PARAM<br>
makes me cringe.<br>
<br></blockquote><div><br></div><div>Would this be reasonably avoided with any of the above suggestion?<br> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
Plus, it won't stop with datetimes.<br></blockquote><div><br></div><div>The thing is that it probably shouldn't, because the current votable datatypes and xtypes are not enough anyway, and xtype already goes beyond simple primitive type (e.g. xtype="point"). On the other hand, there can't be too many primitive types. Yes, we could make mistakes, have too few primitive types or we could compromise our way to self-destruction by introducing primitive types for everything, but that seems reasonably avoidable with the emerging framework.<br><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">
</span>Is that a benefit proportional to forcing VOTable implementors to<br>
supporting a second, incompatible type system with its own rules for<br>
serialisation?<br>
<br>
As I said, VODML annotation will do extremely basic things in the<br>
future. I don't see how any VOTable library could get away with not<br>
supporting it.<br></blockquote><div><br><div>I wouldn't like to give up a better mechanism
because we currently have what you claim to be a sub-optimal one. At the
same time you make some good points about having to compromise to make life easier for implementors, and it would be good to find a reasonable compromise. To me the compromise is in turning the "incompatible" above to "compatible". Is that possible without dumbing down the syntax?<br></div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
<span class="gmail-"><br>
> Also, it was decided that the dmtype would be mandatory even if the type is<br>
> not being cast to a more specific type than the one declared for a Role?<br>
><br>
> Would you want to remove that requirement form the mapping?<br>
<br>
</span>Since the requirement doesn't seem to be something that makes<br>
client's lives easier, I'm all for removing it, yes.<br></blockquote><div><br></div><div>It depends on the client, though. How does xtype="timestamp" make client's lives easier? Isn't it "just a string" for a lot of use cases? Thing is, there are use cases where knowing that something is a timestamp, and assuming some domain knowledge about times, is rather useful, especially in astronomy (hello, Capt. Obvious). The same should be true for other primitive types. Not many, but the current votable datatypes don't help either, as you and Gerard pointed out earlier from different angles.<br><br></div><div>By the same token, there will be clients that know about specific roles, and so they don't need the extra type information, and clients that don't know about roles for a lot of models but they still care about the primitive types, e.g. a datetime/timestamp. And yes, there will be clients that won't care about datetime/timestamps and just want to know it's a string of characters.<br></div><div><br></div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">
<br>
</span>Since you mention it: Why not? Sure, an extra reference is involved,<br>
which is always bad, but as far as I can see there's nothing you can<br>
do with LITERAL that you can't do with CONSTANT, and one feature less<br>
is always a big win.<br>
<br></blockquote><div><br></div><div>I have mixed feelings about this. I like the idea that the new VODML element could represent a standalone annotation, which means you need LITERAL.<br></div><div><br><div>To recap:<br></div><div> 1. my personal Yay! to removing the ivoa model from the current VODML PR.<br></div><div> 2. I believe it's important to have the extra flexibility and standardization that goes beyond the votable datatypes, and the ivoa primitive types represent that.<br></div><div>
3. I believe it's important to require the dmtype on LITERAL, for
clients that are model-unaware but know how to deal with primitives (and dmtypes go beyond votable datatypes because of point 2.)<br></div><div> 4. We should make sure we keep the ivoa model close to what was already introduced, so to make the type systems compatible.<br></div><div>
5. We should carefully decide what goes and what doesn't go in the list
of primitive types. Too few and we lose semantics, too many and
interoperability is hurt. Maybe we should even constrain primitive types
to only be defined in the ivoa model.<br><br></div>And I think
it's good to have a mechanism that goes beyond the current
limitations/complexity of VOTable. How many attributes do FIELDs and
PARAMs have in order to describe what of a piece of (meta)data is?
xtype, utype, datatype, ucd, as well as the deprecated 'type', I
believe. That could be fixed in the new LITERAL element by having only
one dmtype element, which uniquely describes the type, and by a sane set
of primitives. Some compromises might make it a little bit more
complex, but hopefully not too much.<br><br></div><div>Omar.<br></div><div> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
$ python -c "import this" | grep preferably<br>
There should be one-- and preferably only one --obvious way to do it.<br>
<br></blockquote><div><br></div><div>Yet Python is a rather bad example of this (not as bad as perl!), at least as soon as you go beyond the basic syntax and start doing something useful with it. True, they are slowly fixing this in Python 3, by adding new, admittedly saner ways of doing the same things you could do in Python 2. And idiomatic Python can sometimes be far from obvious for beginners. The very existence of an "idiomatic Python" defeats the rule above, which is one of the reasons I think there is a telling second part of the rule: "Although that way may not be obvious at first unless you're Dutch." ;)<br><br></div><div>[Teasing mode off]<br></div><div><br></div><br></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr">Omar Laurino<br>Smithsonian Astrophysical Observatory<br>Harvard-Smithsonian Center for Astrophysics<div><font color="#999999">100 Acorn Park Dr. R-377 MS-81</font></div><div><font color="#999999">02140 Cambridge, MA</font><br><span style="color:rgb(153,153,153)"><a style="color:rgb(17,85,204)" value="+16174957227">(617) 495-7227</a></span></div></div></div>
</div></div>