<div dir="ltr">Hi Gerard,<br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 10, 2015 at 12:32 PM, gerard.lemson@gmail <span dir="ltr"><<a href="mailto:gerard.lemson@gmail.com" target="_blank">gerard.lemson@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br>
In this context, some of my questions are:<br>
1) is my characterisation of naive clients above correct, and if not<br>
complete, what does it miss?<br></blockquote><div><br></div><div>The definitions for so called naive, advanced, and guru clients are in the old Mapping document, i.e. the one we presented in Heidelberg:</div><div><a href="http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/UTYPEs-WD-v.0.x.pdf">http://volute.googlecode.com/svn/trunk/projects/dm/vo-dml/doc/UTYPEs-WD-v.0.x.pdf</a><br></div><div><br></div><div>I report them here for convenience:</div><div><br></div><div>This document defines a complete, unambiguous, standard specification that can be
used to serialize and de-serialize instances of Data Model types. It was designed to be
simple and straightforward to implement by Data Providers and by different kind of
clients.</div><div><br></div><div>We can classify clients in terms of how they parse the VOTable in order to
harvest its content. Of course, in the real word such distinction is somewhat fuzzy, but
this section tries and describe the different levels of usage of this specification.</div><div><br></div><div>Naïve clients</div><div>We say that a client is naïve if:</div><div> i) it does not parse the VO-DML description file</div><div> ii) it assumes the a priori knowledge of one or more Data Models</div><div> iii) it discovers information by looking for a set of predefined UTYPEs in the VOTable
In other terms, a naïve client has knowledge of the Data Model it is sensitive to, and
simply discovers information useful to its own use cases by traversing the document,
seeking the elements it needs by looking at their @utype attribute.
Examples of such clients are the DAL service clients that allow users to discover and
fetch datasets. They will just inspect the response of a service and present the user with
a subset of its metadata. They do not reason on the content, and they are not interested
in the structure of the serialized objects.
If such clients allow users to download the files that they load into memory, they should
make sure to preserve the structure of the metadata, so to be interoperable with other
applications that might ingest the same file at a later stage.</div><div><br></div><div>Advanced clients</div><div>We say that a client is advanced if:</div><div> i) it does not parse the VO-DML description file</div><div> ii) it is interested in the structure of the serialized instances</div><div> iii) can follow the mapping patterns defined in this specification, for example
collections, references, and inheritance41</div><div><br></div><div>Examples of such clients are science applications that display information to the user in
a structured way (e.g. by plotting it, or by displaying its metadata in a user-friendly
format), that reason on the serialized instances, perform operations on those instances,
and possibly allow the users to save the manipulated version of the serialization.
Notice that the fact that an application does not directly use some elements that are out
of the scope of its requirements does not mean that the application cannot provide them
to the user in a useful way. For example, an application might allow users to build
Boolean filters on a table, using a user-friendly tree representing the whole metadata.
This exposes all the metadata provided by the Data Provider in a way that might not be
meaningful for the application, but that may be meaningful for the user.
Notice, also, that advanced clients may be DM-agnostic: for instance, an Advanced Data
Discovery application may allow the user to filter the results of a query by using a
structured view of its metadata, even though it does not possess any knowledge of Data
Models.</div><div><br></div><div>Guru clients</div><div>We say that a client falls into this category if:</div><div> i) it parses the VO-DML descriptions</div><div> ii) it does not assume any a priori knowledge of any Data Models.</div><div><br></div><div>Such applications can, for example, dynamically allow users and Data Providers to map
their files or databases to the IVOA Data Models in order to make them compliant, or
display the content of any file annotated according to this standard.
This specification allows the creation of universal validators equivalent to the XML/XSD
ones.
It also allows the creation of VO-enabled frameworks and universal libraries. For
instance, a Python universal I/O library can parse any VOTable according to the Data
Models it uses, and dynamically build objects on the fly, so that users can directly
interact with those objects or use them in their scripts or in science applications, and
then save the results in a VO-compliant format.
Java guru clients could automatically generate interfaces for representing Data Models
and dynamically implement those interfaces at runtime, maybe building different views of
the same file in different contexts.
Notice that Guru frameworks and libraries can be used to build Advanced or even Naïve
applications in a user-friendly way, abstracting the developers from the technical details
of the standards and using first class scientific objects instead.</div><div><br></div></div><br><br clear="all"><div><br></div>-- <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 value="+16174957227" style="color:rgb(17,85,204)">(617) 495-7227</a></span></div></div></div>
</div></div>