Proposal to split out the "members" from coreQ (Was: Re: Philosophy of basic Q)

[Brian Thomas]

	David, 

On Wednesday 12 May 2004 11:53 am, David Berry wrote:
> > > > I don't believe it is too late to revise this to separate out the
> > > > "member" stuff from Core/Standard Q and put it in a separate
> > > > interface. What do other people think?
> > >
> > > I think that this is all new stuff which I for one have not seen
> > > clearly defined or justified anywhere. I think you need to start from
> > > the beginning and say clearly what a QuantitySet is and why it is
> > > needed.
> >
> > You have seen it, it exists in the current serialization. The language is
> > just perhaps different from what you have heard before.
>
> But there is no evidence of it in the interface, and does there need to
> be? 

	CoreQ has "getMembers()". The add/removeMember methods appear
	to be dropped from the 0.5 document, but that may be because the
	intention is to use "setValue(Obj,loc)", which I think is bad.

> What benefits do your suggestions give us in terms of the actual *data
> model* (as described by the interface) rather than in the specific form of
> the serialisation you suggest in the doc? 

	I have already described this. But here it is again, please read :

1. CoordsQuantity is a Q which holds other Q's (the dimensions/axes).
It doesn't hold values.. it holds only other Q's. Therefore, even if it is currently
called a CoreQ, it is a special one, which doesn't hold values (number/strings)
but objects instead as its "data". A separate interface is probably the cleaner way
to implement this.

2. You can use CompositQ/Quantity to build tables and more complex Q's as
(I anticipate) will be needed by other higher -level DM modelers.


> How would it related to other serialisations such as FITS?

	In Fits, I'm not sure.. perhaps as a "Field Axis" which groups together fields
	in a FITS table.

> I know I've said it before, but there is no harm in saying it again - the
> fact that the suggested serialisation in the doc does not clearly have a
> one-to-one connection with the data model is, I think, one of the main
> problems with the doc.

	Well, if we want one-to-oneness, its not a show stopper for me. 

>
> I always thought we were way ahead of ourselves in diving into
> serialisations before we had firm agreement on the data model which we
> were supposed to be serialising!

	Hurm. It would have been far better to bring this up privately or
	before release of the 0.5 document if you had such serious reservations.

	=b.t.

>
> David
>
> > > ----------------------------------------------------------------------
> > > Dr David S. Berry    (dsb at ast.man.ac.uk)
> > >
> > > STARLINK project		 |	Centre for Astrophysics
> > > (http://www.starlink.ac.uk/)	 |	University of Central Lancashire
> > > Rutherford Appleton Laboratory	 |	PRESTON
> > > DIDCOT				 |	United Kingdom
> > > United Kingdom			 |	PR1 2HE
> > > OX11 0QX                                Tel. 01772 893733
> > >                                              01257 273192
> >
> > --
> >
> >   * Dr. Brian Thomas
> >
> >   * Dept of Astronomy/University of Maryland-College Park
> >   * Code 630.1/Goddard Space Flight Center-NASA
> >
> >   *   fax: (301) 286-1775
> >   * phone: (301) 286-6128 [GSFC]
> >            (301) 405-2312 [UMD]
>
> ----------------------------------------------------------------------
> Dr David S. Berry    (dsb at ast.man.ac.uk)
>
> STARLINK project		 |	Centre for Astrophysics
> (http://www.starlink.ac.uk/)	 |	University of Central Lancashire
> Rutherford Appleton Laboratory	 |	PRESTON
> DIDCOT				 |	United Kingdom
> United Kingdom			 |	PR1 2HE
> OX11 0QX                                Tel. 01772 893733
>                                              01257 273192

-- 

  * Dr. Brian Thomas 

  * Dept of Astronomy/University of Maryland-College Park 
  * Code 630.1/Goddard Space Flight Center-NASA

  *   fax: (301) 286-1775
  * phone: (301) 286-6128 [GSFC]
           (301) 405-2312 [UMD]