Spectral DM document update

[Pedro Osuna]

Dear all,

in our (ESA-VO collective) view, a Data Model should be an abstract
description. No implementation (or serialisation(s)) issue should
dictate the direction of a model. On the other hand, not Data Model
should impose "how to serialise it to be useful".

>From the point of view of application writers, we don't care whether the
data come in vector or in points. It will take us more or less effort to
parse them, but will write a parser once and re-use it where adequate. 

The point is not whether it makes sense to parse points or not, or
whether 'standard' parsers can do certain things and not others. 

We believe the point is that, in this particular case, a 1D Spectrum
(e.g., with hundred thousand points) ought not be described in the same
way (model) as an individual isolated photometric point. In fact, in our
view a Photometric point should be modelled with a different Data Model,
containing: the magnitude value, the reference zero point and flux, and
eventually any transmission function that might play any role in an
eventual -inverse- integration to get the flux (plus whichever other
relevant bits).

Therefore, we advocate for Data Models which do not depend on their
implementation and are not driven by it. If Photometry has to be treated
differently from a 1D-Spectrum, then create a specific model for it.


Since someone asked, our 2cents.

Cheers,
P.



On Mon, 2006-10-09 at 21:17 -0600, Doug Tody wrote:
> Hi All -
> 
> This discussion seems to have died down for the moment; hopefully some
> others will post as well, particularly as the Europeans come back online
> tomorrow.
> 
> An important point here is that if we put an API in front of Spectrum,
> the details of the XML serialization are not all that important.  The API
> library can support multiple serializations and resolve any differences
> between them, exposing an in-memory model to client applications which
> is *indendent of external representation*.  If the API wants to present
> vectors to the client it can turn Point objects into vectors, or extract
> vectors from the columns of tables; if it wants to present a Point-model
> it can turn vectors or columns into Points, or whatever is required.
> 
> The specfic XML serialization only matters much when we deal with the
> XML representation directly.  This happens if we use XML schema-based
> code generation tools to autogenerate a data binding, in which case if
> we have an array of Points in the schema, that is what the resultant
> API will present.  Another case is when XML-specific tools are used to
> access the XML directly.  In this case the vector approach may again
> be better, as a reference to a single node in the serialization could
> recover a data vector in one step, allowing it to be easily extracted
> and used in tools; otherwise such a data vector could be quite hard to
> extract.  The tag-everything approach makes it easy to get at a single
> array element, but not the whole array, which is the wrong approach for
> something like a spectrum.
> 
> None of this has much to do with SOAP or the peculiarities of specific
> SOAP implementations, or where SOAP is appropriate to use or otherwise.
> That is an important issue too, which has not been adequately discussed,
> but is largely a separate issue.
> 
> 	- Doug
> 
-- 
Pedro Osuna Alcalaya

European Space Agency (ESA)
European Space Astronomy Centre (ESAC)
Research and Scientific Support Department (RSSD)
Astronomy Science Operations Division (SCI-SD)
e-mail: Pedro.Osuna at esa.int
Tel + 34 91 813 13 14    Fax: +34 91 813 11 72
-------------------------------------------------                                                                                
European Space Astronomy Centre (ESAC)
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN