Defaults in STC

[Guy Rixon]

Anita,

XML distnguishes a value, an empty value (i.e. nothing between the start and
end tags of the element) and a null (via the nil="true" attribute).  It
doesn't distinguish "uknown" from "not applicable", nor do relational
theory and DBMS products. We should be cautious of introducing distinctions
not supported by the technology.

AFAIK, "unknown" is supposed by the theories to be represented by a null. "Not
applicable" would also be represented as a null in a relational schema. In a
hierarchical schema, as in XML, it might also be represented by a variant
schema that omits the inapplicable elements; i.e. if we have elements that are
only sometimes valid, then we should use substitution groups to eliminate the
invalid cases.

I'm particularly keen to protect the integrity of the XML schemata. If our
schemata are clean, then we can expect some support from third-party tools and
our use of web services is easier. If we make all kinds of special
arrangements, then our schemata are corrupt and may not work where we need
them to. To this end, we should not allow authors to write "unknown" where an
number is expected.

I suggest this:

 1. Any omissible elements should be marked nilable="true" in the schemata;
    this is part of the modelling.

 2. Any omitted elements in an instance of the model should be made null:
    either a relational null or nil="true" in XML.

 3. If we need to distinguish kinds of null then, in XML at least, write an
    annotation tag with an English note.

 4. If we need our programmes to distinguish different kinds of null then,
    in XML, put an appinfo element inside the annotation element, the former
    containing a code for the type of null.

Cheers,
Guy

On Sat, 9 Oct 2004, Anita Richards wrote:

>
> Thanks Guy,
>
> Yes, we should conform to XML standards where applicable.  However in some
> cases (probably not here, but e.g. in the Registry) it is useful to
> distinguish between 'unknown' and 'not applicable' - or does XML do that,
> too?
>
> cheers
> a
>
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> Dr. Anita M. S. Richards, AVO Astronomer
> MERLIN/VLBI National Facility, University of Manchester,
> Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
> tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
>
>
> On Sat, 9 Oct 2004, Guy Rixon wrote:
>
> > "Unknown" is, technically,  a null value.  XML has a specific way of
> > expressing nulls: the nilable attribute in the schema and the nil (Sp?)
> > attribute in the instances.  I suggest that we use this rather
> > than just writing a value of "Unknown".
> >
> > On Thu, 7 Oct 2004, Anita Richards wrote:
> >
> > > > There are two kinds of uncertainties, especially for historical data.
> > > >
> > > > One is "I don't know exactly when this plate was taken - it was in
> > > > 1925 or 1926".
> > > > In principle, the observing time range, coupled with the observatory
> > > > location, should give one a huge uncertainty in Doppler velocities, so
> > > > no special provisions are needed.  And inaccuracies in, say, positions
> > > > can be handled through the error elements.
> > > >
> > > > The other is "unknown": "I don't know whether this velocity is radio
> > > > or optical definition, etc".
> > > > I think the only reasonable way to handle this, if we must, is to
> > > > allow "Unknown", "Not available", or something like it, as an allowed
> > > > value.  It does put the bruden on the user to figure out (a) whether
> > > > the data are still useful, and (b) if needed, what would be a
> > > > reasonable guess for a default.
> > > >
> > > > So, somewhat reluctantly, I am leaning toward accepting the concept of
> > > > "Unknown" as allowed value for a number of coordinate system elements.
> > > > If I understand your previous message correctly, you would agree with
> > > > that solution.  Correct?
> > >
> > > Thanks, yes, that is all exactly what I was trying to say, with the added
> > > proviso that (as you mention in the original document), e.g. velocity
> > > convention = "unknown"  would cause problems for software using the model
> > > to deduce redshift from velocity _unless_ the application software
> > > intrpreted "unknown" as e.g. optical convention and added the appropriate
> > > error; knowing a redshift to a low accuracy might still be very useful.
> > >
> > > That would be outside the province of the STC model but is something whcih
> > > people writing applications could take care of.  Does that sound sensible?
> > > (i.e. caveat emptor, and your model stays pure :)
> > >
> > > cheers
> > >
> > > a
> > > - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> > > Dr. Anita M. S. Richards, AVO Astronomer
> > > MERLIN/VLBI National Facility, University of Manchester,
> > > Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K.
> > > tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax).
> > >
> >
> > Guy Rixon 				        gtr at ast.cam.ac.uk
> > Institute of Astronomy   	                Tel: +44-1223-337542
> > Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523
> >
>

Guy Rixon 				        gtr at ast.cam.ac.uk
Institute of Astronomy   	                Tel: +44-1223-337542
Madingley Road, Cambridge, UK, CB3 0HA		Fax: +44-1223-337523