Spectral DM document update

[Gilles DUVERT]

Hi Doug,

I was online yesterday and saw the discussion rage, but since you said 
"None of this may matter in the end as most people will probably use 
VOTable and FITS for spectra", i refrained to comment that a 
single-point spectrum is not a spectrum at all.. :-) .

After all, I told myself, all that matters is what the API will show, or 
the serialization contain, and personnally I will want to see and use an 
array, since everything that you can do wth a spectrum is done 
vectorially (calibration, fourier analysis, model fit, etc...).

Now, since I perceived an uneasiness with the current Point-model, I  
looked into it  more closely, with my "vector" model in mind. I feel 
that, to reconstruct an array from the Point-model, one needs either to 
have the Sampling object in the Spectrum model, or at the very least, 
have Accuracy.BinSize and/or Accuracy.BinLow, Accuracy.BinHigh 
*mandatory* instead of OPT, since how are we going to reconstruct an 
useable spectrum from points if this (poor) information is not here?  
And this is only the first example that comes to mind, there may be others .

So, I guess I support entirely your concern. By destroying the natural 
bonding of spectra elements as members of a vector (*), this leaves too 
much unknowns for the future implementations. I would say that since 1) 
the known and working serializations ARE "array-dominated" and 2) the 
Point-model leaves too much to be done manually before retrieving a good 
spectrum, then just leave the point model and switch to an array based 
model.

There was a comment about parsers and code binders that are unable today 
to read arrays. I hope this is only temporary, and, anyway, I do not see 
why a DataModel could be polluted by such indirect requirements. 
Besides, either you place the "hard work" on the parser, or on the 
users. Since the parser is of order unity, and the users many, the 
choice is done.

As usual, sorry in advance for the rudeness of my comments (hopefully 
due to bad english courses), and congrats to all the people involved in 
the writing of the SDM document.

Best

Gilles
(*) how in the model do you know that two Points follow each other in 
the resulting spectrum? By the order of arrival of the <Point> tag in 
the <Data> ? Is this really "safe"?

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
>
>   
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Gilles.Duvert.vcf
Type: text/x-vcard
Size: 382 bytes
Desc: not available
URL: <http://www.ivoa.net/pipermail/dm/attachments/20061010/f3621918/attachment-0001.vcf>