Re: [Xmlastro-discussion] Weather, etc. Was: Multiple Objects

[Tom W. <dev...@to...>]

On Mon, 31 Mar 2003 16:37:10 -0500 (EST), Peter C. Chapin 
<pc...@ec...> wrote:

>
> A related thought: Should we put some kind of version number into the
> namespace identifier we are using as a targetNamespace? One supposes that
> in the future there might be a version 2.0 of whatever we are producing.
> People will want to distinguish that from version 1.0.

I think we'd only need to change the version number in the namespace if the 
actual structure of the schema changed in a way that would invalidate 
previous instances. Probably best to be prepared for this, so why not? 
There is also the version attribute of <schema...> root element, although 
don't think this get's parsed in validation - purely for show!?

> I used the same (value, notes) pairing for all data-like quantities. The
> value element has an attribute for the units (tempunitsType is either "C"
> or "F" but other quantities have other types of units, of course). The
> notes element is supposed to contain additional relevant information or,
> if the observer lacks a "precise" value, the notes element can contain 
> the
> observer's informal estimate. Thus
>
> <temperature>
> <value units="C">-1.9</value>
> <notes><p>Measured using the thermometer on my back porch</p></notes>
> </temperature>
>
> Both value and notes are optional, of course.
>
> <temperature>
> <notes><p>Cold! It is definitely below freezing.</p></notes>
> </temperature>
>
> I wanted to give document authors the option of just describing a 
> quantity
> as well as providing a numeric value for it. In some cases where I didn't
> know of a way to provide a numeric value for a quantity I still followed
> the same pattern (just removed the <value> element). I figured that
> perhaps one day in the future a proper value element could be defined for
> such a quantity. Although I didn't include a specific cloud-cover element
> in what I did, I could imagine handling it the way I just described.
>
> <cloud-cover>
> <!-- <value> ??? </value> -->
> <notes><p>About half the sky is completely obscured by clouds. Only the
> south and west are open.</p></notes>
> </cloud-cover>

I like this. A nice simple approach, with the same structure for each 
weather element.

> One imagines that a full featured weather schema would include a place to
> record the types of clouds and all that. I'm not sure if we need to go
> there.

Probably not. In a *complete* weather schema cloud cover would probably be 
represented by the types of clouds as well, and we certainly don't need 
that, perhaps this is the sort of thing an observer could just record in 
the notes. Although I think an optional <transparency> or <visibility> 
element could be used to represent this. Perhaps with a scale, or just 
simple type string.
<visibility>excellent</visibility>

> This sounds like potentially a difficult issue. Since the weather changes
> with time a serious effort of capturing weather information would have to
> allow for instance documents to contain multiple weather observations at
> different times.

I agree it is hard to describe and probably beyond the scope of astroXML. 
But I do like the idea of giving the option to be able to record more than 
just a static measurement. My weather instrumentation tells me 
automatically variation in pressure and temperature, so when I do an 
astronomy session, I will also record whether the pressure and temperature 
are rising or falling, and sure this is the case for others. These could be 
simple optional attribute inclusions in the corresponding element perhaps?

Maybe the best way to go, for now, would be to use <xs:anyType> in the 
schema so that the weather type can be provided at instance creation from 
another schema doc/namespace? This would allow us to provide the 
value/notes temperature type and allow an author to structure something 
more complex if required, OR the incorporation of a more well-defined 
weather schema if one is created????

Tom