<html>
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix">Hi Omar<br>
      On 15/12/2015 19:08, Laurino, Omar wrote:<br>
    </div>
    <blockquote
cite="mid:CAFwvi4tKwzmhF7j97PhmXMoQuKnkeYO0byVz5NJBHB9ExWmYdQ@mail.gmail.com"
      type="cite">
      <meta http-equiv="Context-Type" content="text/html; charset=UTF-8">
      <div dir="ltr">
        <div class="gmail_extra">Francois,</div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Tue, Dec 15, 2015 at 11:55 AM,
            François Bonnarel <span dir="ltr">&lt;<a
                moz-do-not-send="true"
                href="mailto:francois.bonnarel@astro.unistra.fr"
                target="_blank">francois.bonnarel@astro.unistra.fr</a>&gt;</span>
            wrote:<br>
            <blockquote class="gmail_quote">PS : I am not considering
              here any kind of serialisation of these VO-DML
              decscriptions (Object relational maaping, VOTABLE Mapping,
              specific-stc2-xml-schema xml  documents, json, etc... ).
              this is another story but the initial VO-DML description
              will constraint the solution. </blockquote>
          </div>
          <br>
          I mostly agree. However, one of the benefits of VO-DML is to
          have a language that can easily be mapped to a variety of
          contexts, including OO languages and relational databases, and
          so ORM. If variable length arrays were impossible (or very
          hard) to treat in ORM, then they should be left off the
          language, because they would be impossible (or very hard) to
          treat in a fundamental set of implementations.</div>
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">But yes, the implementation details of
          how to map VO-DML model instances to a serialization is a
          different topic. So for instance, a model might call for a
          great number of Object Type instances, but specific
          serialization or representation formats might allow more
          efficiency, whether we are talking about Java objects or SQL
          tables, or FITS. An image might have, in principle, an Object
          Type representation for each pixel in an image, but a FITS
          representation might factor out all the common metadata into a
          single representation for all the pixel in the image.</div>
      </div>
    </blockquote>
    I think I agree with all that<br>
    <blockquote
cite="mid:CAFwvi4tKwzmhF7j97PhmXMoQuKnkeYO0byVz5NJBHB9ExWmYdQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra"> I say in principle because I am not
          sure I can take a side in the modeling part per se, so I don't
          have an opinion on whether a pixel should be an Object Type or
          a Data Type, in this example.</div>
      </div>
    </blockquote>
    It is really strange for me to have coefficients as independant
    Objects (instances of ObjectType). <br>
          - Semantically a coefficient is basically just a number and
    become a coefficient only in the context of polynomial. And we want
    anything done for polynomials in the STC model to be independant of
    the order<br>
          - As both Arnold and Laurent stated in different wordings one
    of the usage of UML (and attached VO-DML description) is generation
    of code. ObjectType will become classes and having instances of that
    for "coefficient" and "pixel" will lead to considerable overhead.<br>
    <br>
    Cheers<br>
    François      <br>
    <blockquote
cite="mid:CAFwvi4tKwzmhF7j97PhmXMoQuKnkeYO0byVz5NJBHB9ExWmYdQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">Omar.</div>
        <div class="gmail_extra"><br>
          <div><br>
          </div>
          -- <br>
          <div class="gmail_signature">
            <div dir="ltr">Omar Laurino<br>
              Smithsonian Astrophysical Observatory<br>
              Harvard-Smithsonian Center for Astrophysics
              <div>100 Acorn Park Dr. R-377 MS-81</div>
              <div>02140 Cambridge, MA<br>
                <span><a moz-do-not-send="true" value="+16174957227">(617)
                    495-7227</a></span></div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>