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

[Peter C. C. <pc...@ec...>]

On Mon, 31 Mar 2003, Tom Wright wrote:

> Perhaps to start with we can make use of the *chameleon* effect by
> creating separate schema docs without a target namespace for
> weather/people/location etc. and just use <xsd:include>. Then as the
> schema doc develops could decide on homogenous or heterogenous namespace
> design. Might be an idea to embed the elements for these models in type
> definitions, rather than global, so we can still control namespace
> exposure with the elementFormDefault switch.

Sounds like a good plan to me.

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.

> Weather data to define:
> 1) Temperature - F/C
> 2) Pressure - MB, Hp and perhaps mmHg inHg?
> 3) Relative Humidity - %
> 4) Cloud cover - scale or perhaps just as a note?
> 5) Wind speed - Beaufort scale
> 6) Wind direction - Compass direction

This all seems reasonable to me.

In my sky conditions schema experiments I handled, for example,
temperature like this:

  <xs:element name="temperature">
    <xs:annotation>
      <xs:documentation>The temperature element contains a recording if
the air temperature at the time of the observation. The value child
element contains a precise measurement of the temperature and the notes
child element contains an informal description of the
temperature.</xs:documentation>
    </xs:annotation>
    <xs:complexType>
      <xs:sequence>
        <xs:element name="value" minOccurs="0">
          <xs:complexType>
            <xs:simpleContent>
              <xs:extension base="xs:float">
                <xs:attribute name="units" type="tempunitsType"/>
              </xs:extension>
            </xs:simpleContent>
          </xs:complexType>
        </xs:element>
        <xs:element name="notes" type="notesType" minOccurs="0"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>

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>

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.

> I think the difficulty here is how to represent the relationships
> between the weather observations and the conditions for the observation.
> The weather measurements taken at the time of the observation may
> actually be less relevant to the *quality* of that observation than the
> change in weather over the last few hours.

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. Of course the times when the weather is observed and the
time when the stars are observered are probably different in many cases.
It's hard to see how to combine them in a sensible way.

Peter