xmlastro-discussion — The public mailing list for the xmlastro project.

Re: [Xmlastro-discussion] Schema formatting.

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

On Wed, 7 May 2003, Don Willems wrote:

> >What are people's views on this matter? Fundamentally the way the raw
> >document should look will depend on what people are using for editors. It
> >seems like we need to make a statement about that since the defaults of
> >one editor are likely to undo the changes made by another. Programmers
> >have style conventions to address this sort of issue. Are there similar
> >practices in the XML community?
> >
> I'm not sure, but I agree that it is something we should address.

I looked around some on the 'net but I didn't find a whole lot. I did find
one document created by a company that wanted all the XML produced to have
a similar look. The document spelled out how blank lines were to be used,
indentation depth, maximum line width, and other such things. It read very
much like a style guide for programming and was no doubt inspired by such
things. The document probably only made sense for the case when everyone
was editing their XML with text editors. It seems like XML editors are
more inclined to present the XML in an abstract way and tend to shield
their users from the raw file format.

The "output formatting" topic in XMLSpy's help shows the dialog where you
can control the way XMLSpy "opens and saves documents". There aren't a
whole lot of options suggesting to me that this is not something the
makers of XMLSpy have spent much time worrying about.

Peter

Re: [Xmlastro-discussion] Schema formatting.

[Don W. <don...@ma...>]

>
>
>If I were working on this project alone I would definitely go with a
>reformatting like this. However, maintaining such a format might be
>difficult for people using editors that are not text editors. For example
>it seems that XMLSpy removes the blank lines... an aspect of that editor
>that I find highly annoying. Also XMLSpy won't automatically break a line
>in an element...  meaning that one has to manually manage all the line
>breaks. That's a major drag. (In contrast Emacs can wrap them for me
>automatically without disrupting the rest of the document).
>
I use oXygen as XML editor. It has a pretty-print function, which works 
reasonably well. You can specify how many characters you want on one 
line. On the other hand, it does remove blank lines and even more 
annoyingly it sorts the attributes alphabetically per element. 
Fortunately it is not something you'll have to use.

>What are people's views on this matter? Fundamentally the way the raw
>document should look will depend on what people are using for editors. It
>seems like we need to make a statement about that since the defaults of
>one editor are likely to undo the changes made by another. Programmers
>have style conventions to address this sort of issue. Are there similar
>practices in the XML community?
>
I'm not sure, but I agree that it is something we should address.

Don

[Xmlastro-discussion] Schema formatting.

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

In the past I've experimented with XMLSpy for schema editing. However, it
seems to take away some of my control regarding the layout of the schema
file itself. This results in a schema file that is less readible and less
easily printed as a plain text document than it should be.

I teach courses in programming and I tell my students to restrain
themselves when formatting source code and to limit the lengths of lines
to 80 characters maximum. In todays world of large, graphical displays
such a limitation seems crazy. But when I tell my students to print their
programs... with sufficient margins to bind the papers into a report...
the need to keep line lengths down becomes clear.

It can be argued, of course, that printing programs is old fashion but
there are other contexts where text documents need to be displayed and
where there are limited space resources. For example, simple terminals are
often highly limited and even text mode terminal sessions can suffer from
mundane limitations.

The bottom line is that when I need to edit plain text I tend to find
myself, time and again, reaching for a plain text editor. While XMLSpy is
pretty cool and I have enjoyed using it. I seem to gravitate to Emacs when
I write anything serious.

Our current schema document does not look good as plain text. It contains
long lines that will not print well (without invoking a tiny font) and it
lacks blank lines to set off the various sections of the document, making
it hard to visually decode the document's structure. I'm attaching to this
message a version of the schema that is reformatted in a manner that is
more approachable to plain text editing. A few notes:

1. This reformatting introduces runs of whitespace in the
<xs:documentation> elements. In many cases such whitespace existed already
but in some cases it was added where it didn't exist. I don't think this
is a problem because we are mostly using XHTML <p> elements for
documentation and the whitespace is insignificant in XHTML.

2. The CDATA section is not indented, of course.

3. The long patterns in the restricted simple types are not wrapped, of
course.

4. The indentation depth of the original document was 4 (somewhat
inconsistently applied). I usually like to use 2 since a deeper depth
quickly exhausts the limited horizontal space. If I reformatted the
document to use 2, some of the documentation sections would probably "fit"
better.

If I were working on this project alone I would definitely go with a
reformatting like this. However, maintaining such a format might be
difficult for people using editors that are not text editors. For example
it seems that XMLSpy removes the blank lines... an aspect of that editor
that I find highly annoying. Also XMLSpy won't automatically break a line
in an element...  meaning that one has to manually manage all the line
breaks. That's a major drag. (In contrast Emacs can wrap them for me
automatically without disrupting the rest of the document).

What are people's views on this matter? Fundamentally the way the raw
document should look will depend on what people are using for editors. It
seems like we need to make a statement about that since the defaults of
one editor are likely to undo the changes made by another. Programmers
have style conventions to address this sort of issue. Are there similar
practices in the XML community?

Peter

[Xmlastro-discussion] Hello! So... where were we?

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

Greetings all! The list has been very quiet lately. I imagine that, like
me, everyone has been busy with other things. I'm hoping to get things
rolling again, though. The good weather has finally arrived to my part of
the world and I'm looking forward to a good summer of observing!

A few comments:

1. I sent a message to the administrators of StarGazersOnline asking how
they are storing member observation logs and inviting them to participate
in our project.

2. I modified my proposal for handling dates and times. In particular,
following Don's suggestion I split my original datetimeType into two
different types: absoluteDatetimeType and localDatetimeType. Thus we would
be able to specify elements that are absolute times (the usual case) and
that prohibit the use of "pure" local times. Likewise we would be able to
specify elements that are pure local times... such elements would need
some associated geographical information in order to be fully meaningful.

I also defined an absoluteDatetimeRangeType and a localDatetimeRangeType
for describing a range of times. Mixing absolute and local times in a
range doesn't seem to make sense so it is prohibited. However, mixing two
different time formats in a range is okay (for example JD numbers and
standard ISO formatted date/times). The full details are at the end of
this message.

3. As I recall we agreed to add an <object-group> element to the schema to
allow an observation to be made on a collection of closely related or
"involved" objects at once. Shall I go ahead and make that change? It was
something Don originally brought up as I recall so if he wants to finalize
that change that is also fine with me.

4. Some time ago Tom posted a message explaining to me the difference
between xs:any and xs:anyType. I have saved that message for further
study. Perhaps we should use some of the techniques he described to build
"stubs" for some of the larger more complex items of our schema (like
weather or geographic location). So that we could actually produce useful,
valid instance documents without first having to work out every detail.
How do folks feel about that?

Peter

----> datetime summary <----
<?xml version="1.0"?>

<xs:complexType name="absoluteDatetimeType">
  <xs:annotation>
    <xs:documentation><p xmlns="http://www.w3.org/1999/xhtml">This type
    describes a moment in time. Its content is several mutually
    exclusive options for representing dates and times. The options are
    described as follows.</p>

    <p xmlns="http://www.w3.org/1999/xhtml"><b>JD</b>: The Julian Date
    as a decimal value. The JD is defined in terms of date/time at 0
    degrees of longitude. Thus it is not necessary to include specific
    time zone information.</p>

    <p xmlns="http://www.w3.org/1999/xhtml"><b>ISO</b>: The full date
    and time. This element is the same as xs:datetime except that the
    time zone information is required.</p>

    <p xmlns="http://www.w3.org/1999/xhtml"><b>date</b>: The date alone
    in ISO format. This element is the same as xs:date except that the
    time zone information is required. It is intended to be used in an
    observation set to define a common date for all observations in the
    observation set.</p>

    <p xmlns="http://www.w3.org/1999/xhtml"><b>time</b>: The time alone
    in ISO format. This element is the same as xs:time except that the
    time zone information is <em>prohibited</em>. It is intended to be
    used in an observation when a date (and time zone) are provided in
    an enclosing observation set. In that case it inherits the date and
    time zone from the observation set. Using this element in a case
    where there is no date and time zone to inherit is
    undefined.</p></xs:documentation>
  </xs:annotation>
  <xs:choice>
    <xs:element name="JD"   type="xs:decimal"/>
    <xs:element name="ISO"  type="ISOdatetimeType"/>
    <xs:element name="date" type="ISOdateType"/>
    <xs:element name="time" type="ISOtimeType"/>
  </xs:choice>
  <xs:attribute name="resolution" type="xs:duration"/>
</xs:complexType>

<xs:complexType name="localDatetimeType">
  <xs:annotation>
    <xs:documentation><p xmlns="http://www.w3.org/1999/xhtml">This type
    describes a time that is only meaningful at a particular location.
    If an element with localDatetimeType is used, it should only be used
    in a context where sufficient geographical information is available
    to properly interpret the local time.</p>

    <p xmlns="http://www.w3.org/1999/xhtml">There are several local time
    formats supported. Time zone information is prohibited in all local
    time formats since, by definition, the time zone is irrelevant for
    local times. (A local time with a time zone is an absolute time and
    should be recorded in an element with absoluteDatetypeTime).</p>

    <p xmlns="http://www.w3.org/1999/xhtml"><b>LAT</b>: Local Apparent
    Time. This is the time based on the actual position of the sun. It
    is non-uniform since the sun moves at different rates across the
    sky. However, this time is directly observable.</p>

    <p xmlns="http://www.w3.org/1999/xhtml"><b>LMT</b>: Local Mean Time.
    This is the time based on the motion of a fictional "mean sun" that
    moves at a uniform rate across the sky. It differs from LAT by the
    equation of time. Note that LMT varies continuously across a time
    zone.</p>

    <p xmlns="http://www.w3.org/1999/xhtml"><b>LST</b>: Local Standard
    Time. This is the local time that is agreed upon by convention. It
    is constant in a time zone and jumps discontinuously from one time
    zone to another. This is the time most people use in their day to
    day lives.</p>

    <p xmlns="http://www.w3.org/1999/xhtml"><b>LAST</b>: Local Apparent
    Sidereal Time. This is the RA on meridian. It is directly
    observable. It differs from LMT because the sidereal day has a
    different length than the solar day.</p>

    <p xmlns="http://www.w3.org/1999/xhtml"><b>LMST</b>: Local Mean
    Sidereal Time. This is LAST after averaging the effects of
    nutation.</p></xs:documentation>
  </xs:annotation>
  <xs:choice>
    <xs:element name="LAT"  type="ISOtimeType"/>
    <xs:element name="LMT"  type="ISOtimeType"/>
    <xs:element name="LST"  type="ISOtimeType"/>
    <xs:element name="LAST" type="ISOtimeType"/>
    <xs:element name="LMST" type="ISOtimeType"/>
  </xs:choice>
  <xs:attribute name="resolution" type="xs:duration"/>
</xs:complexType>

<xs:complexType name="absoluteDatetimeRangeType">
  <xs:annotation>
    <xs:documentation>This type describes a range of absolute times. The
    start element specifies the earliest time in the range. The end
    element specifies the latest time in the range. Note that the start
    and end times can have separate resolutions and different time
    zones. They might even be in different formats. To be meaningful the
    start and end times in a range must unambiguously ordered. See the
    XML schema specification, "Part 2: Datatypes" for more information
    on ordering date time values.</xs:documentation>
  </xs:annotation>
  <xs:element name="start" type="absoluteDatetimeType"/>
  <xs:element name="end" type="absoluteDatetimeType"/>
</xs:complexType>

<xs:complexType name="localDatetimeRangeType">
  <xs:annotation>
    <xs:documentation>This type describes a range of local times. The
    start element specifies the earliest time in the range. The end
    element specifies the latest time in the range. Note that the start
    and end times can have separate resolutions and different time
    zones. They might even be in different formats. To be meaningful the
    star and end times in a range must unambiguously ordered. See the
    XML schema specification, "Part 2: Datatypes" for more information
    on ordering date time values.</xs:documentation>
  </xs:annotation>
  <xs:element name="start" type="localDatetimeType"/>
  <xs:element name="end" type="localDatetimeType"/>
</xs:complexType>

<xs:simpleType name="ISOdatetimeType">
  <xs:annotation>
    <xs:documentation>This restricted form of xs:datetime requires the
    use of the timezone.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:datetime">
    <xs:pattern value="\d{4}-\d\d-\d\dT\d\d:\d\d:\d\d(\.\d+)?(([+-]\d\d:\d\d)|Z)"/>
  </xs:restriction>
</xs:simpleType>

<xs:simpleType name="ISOdateType">
  <xs:annotation>
    <xs:documentation>This restricted form of xs:date requires the use
    of the timezone.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:date">
    <xs:pattern value="\d{4}-\d\d-\d\d(([+-]\d\d:\d\d)|Z)"/>
  </xs:restriction>
</xs:simpleType>

<xs:simpleType name="ISOtimeType">
  <xs:annotation>
    <xs:documentation>This restricted form of xs:time prohibits the use
    of the timezone.</xs:documentation>
  </xs:annotation>
  <xs:restriction base="xs:time">
    <xs:pattern value="\d\d:\d\d:\d\d(\.\d+)?"/>
  </xs:restriction>
</xs:simpleType>

Re: [Xmlastro-discussion] It's about time.

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

On Tue, 8 Apr 2003, Don Willems wrote:

> Now that I understand your reasons for including the local times better,
> I'm not so sure anymore if we should include geographical data (in the
> time element). As long as we provide a 'non-local' time. Anyway as I
> said before, I think that these different time formats (local and
> not-local) should be in different elements as they are semantically
> different.

I can see what you are saying about that. It is definitely true that local
and non-local times would be used in different contexts so having them in
the same element probably does not make sense. Let me rethink my approach
a bit and report back with an updated proposal in a few days.

Peter

Re: [Xmlastro-discussion] Multiple Objects

[Don W. <don...@ma...>]

>
>
>>Perhaps I'm missing the point but whats wrong with simply having:
>>
>><object> and <objects>
>>
>>The former being singular and the latter, well, plural.
>>    
>>
>
>My only concern about <objects> is that it looks a lot like <object>. It
>might make the documents harder to read than otherwise. That's a minor
>issue, though.
>
>I think Don should go ahead and include <objects> or <object-group> or
>something along those lines into the schema. Regardless of what we call
>it, it seems clear that we need a way to occassionally support multiple
>objects in a single observation.
>
Semantically <objects> and <object-group> seem to be the same, so I'll 
use <object-group>.

Don

Re: [Xmlastro-discussion] It's about time.

[Don W. <don...@ma...>]

>
>
>There are,
>however, some things for which only a true local time makes sense. For
>example if I say something like "the radiant is only in a good position
>for observing after 22:00 local standard time," I'm *not* trying to
>specify a unique moment. The local time 22:00 occurs at a different moment
>in every time zone... yet the statement is still true. The radiant is well
>positioned at a different moment in every time zone; using a universal
>time to describe such a thing is impossible.
>
But is that not a different kind of information?
Mostly time will be used to specify an instant in time.
The data you provide could be part of observing-conditions?

>>Anyway I'm not so sure about all these formats. If I want to include
>>time information of the observation I'd expect at least LST or JD and
>>preferrably UTC.
>>    
>>
>
>Really what you'd want is the <ISO> option or the <JD> option. You
>definitely don't want the <LST> option.
>
Not for specifying an instant of time.

>Certainly it makes no sense to use a local time in a position. On the
>other hand I think there are situations where it makes no (or little)
>sense to include an absolute time with a local time. Perhaps we are trying
>to cover too much ground with one element. Or perhaps this is an example
>of a constraint that must be applied externally to the schema.
>
I can see your point of using the local times. I'm just not sure if they 
specify the same kind of data and if not if they should be part of the 
same element.

>>>It will be common, I think, for a set of observations to occur at
>>>different times on the same date. Note that the time zone information is
>>>inherited by the observation as well as the date.
>>>      
>>>
>>I'm sure if we should do this. Timezone information is not that much, so
>>it shouldn't be to much of a problem to include it in every local time
>>(LST). It will make the information more readable.
>>    
>>
>
>I was more worried about the date than the timezone information. On the
>other hand since the date changes at local midnight... right in the middle
>of the night... tagging each observation with a full datetime might make
>sense. You've expressed reservations about splitting up dates and times
>before and I'm fine with dropping that (mis?)feature.
>  
>
No, I think splitting of date and time is ok.  But even if no time is 
specified, timezone should be used for the date (if the date is not in UTC).

>>Maybe we should include geographical information?
>>    
>>
>
>Certainly the geographical information will influence the interpretation
>of some time formats just as time influences the interpretation of some
>position formats. Ideally an observer would include all relevant
>information in all observations. I'm not sure, though, how far we can go
>in enforcing that with the schema.
>
Now that I understand your reasons for including the local times better, 
I'm not so sure anymore if we should include geographical data (in the 
time element). As long as we provide a 'non-local' time. Anyway as I 
said before, I think that these different time formats (local and 
not-local) should be in different elements as they are semantically 
different.

Don

RE: [Xmlastro-discussion] Multiple Objects

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

On Wed, 2 Apr 2003, Peter Dean wrote:

> Perhaps I'm missing the point but whats wrong with simply having:
>
> <object> and <objects>
>
> The former being singular and the latter, well, plural.

My only concern about <objects> is that it looks a lot like <object>. It
might make the documents harder to read than otherwise. That's a minor
issue, though.

I think Don should go ahead and include <objects> or <object-group> or
something along those lines into the schema. Regardless of what we call
it, it seems clear that we need a way to occassionally support multiple
objects in a single observation.

Peter

Re: [Xmlastro-discussion] Directions

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

On Fri, 4 Apr 2003, Michael Wilson wrote:

> Greetings.

Hello! Thanks for your useful message. I believe some of the concerns you
raise have been discussed in the past, at least partly.

> Firstly: I see lots of activity abou what is and what is not allowable
> within given XML methods. What remains is unclear is a precise purpose of
> this schema. What (precisely) is to be achieved?

Based on conversations between Don and myself, I summarized the audience
for our schema as follows:

----> cut here <----

1. Individual novice to intermediate observers interested in recording
informal observations in way that makes them easier to format or search.

2. Individual intermediate to advanced observers interested in recording
formal, high quality, scientifically significant data. Such observers
might also be using (or want to be using) a relational database as well.
What we do should have the ability to play happily with such systems.

3. Groups (clubs, teams of observers, etc) interested in recording
observations made by the group under various conditions.

4. Individuals or groups interested in exchanging observations or object
information to build a common store of such information. These people may
want to merge observations from different sources into a single document.
What we do should not make it too difficult to do such merges.

5. Not professionals.

----> cut here <----

Some of these points are admitedly a bit vauge and could use elaboration.
Personally, I'm coming at this from position #1. I do mostly "casual"
observing and collect very little hard data. I am looking for a way to
record my observations that will make it easy to put them on the web and
easy to search and index them. I would like, however, for the schema we
produce to have more utility than just that.

> For the human reader or for automated systems?

Don and I agreed that human readibility and writability would be
desirable.

> For potential integration of amateur observation with formal research
> programmes?

This would be great but I don't know much about what it would require. It
sounds like you might have some insight there.

> Secondly: what is the programme? What's to be done first? What sequence of
> capabilities are to be developed?

This is a list of topics of immediate interest taken from past messages to
this list.

----> cut here <----

 1) Structure
 2) Root elements
 3) Object identification
 4) Positions of objects
 5) Time
 6) Location of observing site
 7) Observing conditions
 8) Instrument information
 9) Common observation elements
10) Specific (for object type) observation elements
11) References to external information sources
12) Document-like markup for use in <notes>

----> cut here <----

> Who is motivated to develop them?

I'm motivated to work on the features required to meet my immediate
need. This includes the features mentioned above at least.

> How will they be tested for suitability or completeness?

My view on that is to put the schema into action as soon as possible and
modify it based on real life experience. In fact, I hope to use what we
create as early as this summer (we just got 10 inches of snow here today
so summer is still a ways off).

> Thirdly: considerable traffic has been devoted to issues of capturing the
> details of coordinate systems for both observer location (space and time) as
> well as observed entity. These issues are fundamentally identical to those
> that the geo-science community have been addressing since 1994 in developing
> the FGDC and ISO 19115 standards. Be warned: these are remarkably complex
> issues and a lot of compromises have been tediously negotiated to arrive at
> a workable, yet cumbersome, standard. The geo-science gang are no dummies,
> and have a lot of interest and backing from (earth) mapping authorities, the
> military, GIS vendors and commercial users of geo-data. These players have
> had a LOT mor emoney to throw at the problem than we well-meaning amateurs.
> A lot of hard lessons of been learned. XMLastro could well stand to benefit
> from this experience. One concrete activity could be to review and mine the
> geo-science schemas for useful adaptations for astronomical tasks.

I agree completely. I downloaded the FGDC schema and took a quick look at
it. As you said there is a lot there and it would take time to digest it.
Is this something you'd be willing to look into? It sounds like you are
already at least a little familiar with the work.

> Finally: are we truly convinced that no parallel efforts exist. Sites like
> StarGazersOnline.com offer observation logging and I am sure that there are
> others. Do we have any idea what structures they employ, or any baseline
> against which to compare them for adjusting to future interoperability.

I was not familiar with StarGazersOnline.com but I checked it out after
seeing your message. The log information is interesting; it looks rather
similar to the sort of information we are talking about capturing with our
<observation> element (actually it seems like we are trying to do more).
Anyway, I think it might be nice to send a note to the people who created
that site... and other similar sites that might exist... and see what they
are doing. We could invite them to participate in XMLastro as well.

Peter

Re: [Xmlastro-discussion] It's about time.

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

On Wed, 2 Apr 2003, Don Willems wrote:

> >I introduced restricted versions of xs:datetime, xs:date, and
> >xs:time to control the time zone option. I feel that observers should
> >always include time zone information unless they are specifically
> >recording a local time. I provide different elements for local times to
> >distinguish them from "absolute" times
>
> I don't see that. I would expect timezone information to be included
> specifically with local times (LST). If you're using LAT or LMT I'd
> expect geographical information to be included.

My concept was that most of the time the <ISO> option would be used. That
option requires time zone information. Local times would be employed only
rarely and under special circumstances. For example, in a day-to-day
observation I might record date/time as

<datetime>
  <ISO>2003-04-04T20:30-05:00</ISO>
</datetime>

I don't regard this as a local time even though it's using the -0500 time
zone... which happens to be my local time zone. Unlike a "local"  time,
the time quoted above is intended to specify one unique moment. There are,
however, some things for which only a true local time makes sense. For
example if I say something like "the radiant is only in a good position
for observing after 22:00 local standard time," I'm *not* trying to
specify a unique moment. The local time 22:00 occurs at a different moment
in every time zone... yet the statement is still true. The radiant is well
positioned at a different moment in every time zone; using a universal
time to describe such a thing is impossible.

Another potential place where a true local time makes sense is in
describing twilight. At what time is twilight over? Using a universal time
for that would not be very enlightening and would be somewhat unnatural.

I admit that my proposal contains quite a few "exotic" local time
options... most of which would probably rarely be used.

> Anyway I'm not so sure about all these formats. If I want to include
> time information of the observation I'd expect at least LST or JD and
> preferrably UTC.

Really what you'd want is the <ISO> option or the <JD> option. You
definitely don't want the <LST> option.

> Should we make one of these time formats required and the others LAT,
> LMT,... optional? For times included in a position LAT or LMT should not
> even be allowed to be included in the time information. At least that is
> my opinion.

Certainly it makes no sense to use a local time in a position. On the
other hand I think there are situations where it makes no (or little)
sense to include an absolute time with a local time. Perhaps we are trying
to cover too much ground with one element. Or perhaps this is an example
of a constraint that must be applied externally to the schema.

> >It will be common, I think, for a set of observations to occur at
> >different times on the same date. Note that the time zone information is
> >inherited by the observation as well as the date.
> >
> I'm sure if we should do this. Timezone information is not that much, so
> it shouldn't be to much of a problem to include it in every local time
> (LST). It will make the information more readable.

I was more worried about the date than the timezone information. On the
other hand since the date changes at local midnight... right in the middle
of the night... tagging each observation with a full datetime might make
sense. You've expressed reservations about splitting up dates and times
before and I'm fine with dropping that (mis?)feature.

> Maybe we should include geographical information?

Certainly the geographical information will influence the interpretation
of some time formats just as time influences the interpretation of some
position formats. Ideally an observer would include all relevant
information in all observations. I'm not sure, though, how far we can go
in enforcing that with the schema.

Peter

[Xmlastro-discussion] Directions

[Michael W. <mic...@ho...>]

Greetings.

As one of the original joiners of the list I have been 'luking' for many 
weeks and am now inspired to present some observations and concerns. Some of 
these are based on earlier postings which seem to remain pending issues. I 
hope that resurrecting these may inspire (or provoke) some clarifying 
discussion. I note for the record that I am primarily an astonomer and 
secondarily an XML wonk. I also come at this from a professional system 
integrator's perspective.

Firstly: I see lots of activity abou what is and what is not allowable 
within given XML methods. What remains is unclear is a precise purpose of 
this schema. What (precisely) is to be achieved? Integration and comparison 
of observations? Historical record keeping for posterities sake? For the 
human reader or for automated systems? For potential integration of amateur 
observation with formal research programmes? I have no axe to grind on any 
of these aspects, but wish to note that it is *not* clear from the current 
threads just where the emphasis lies.

Secondly: what is the programme? What's to be done first? What sequence of 
capabilities are to be developed? Who is motivated to develop them? How wil 
they be tested for suitability or completeness? How do we know when we're 
finished? In other words, if we are to avoid a potenetially demotivating 
open-ended task, what are the short -term and other targets, and how will we 
judge our progress?

Thirdly: considerable traffic has been devoted to issues of capturing the 
details of coordinate systems for both observer location (space and time) as 
well as observed entity. These issues are fundamentally identical to those 
that the geo-science community have been addressing since 1994 in developing 
the FGDC and ISO 19115 standards. Be warned: these are remarkably complex 
issues and a lot of compromises have been tediously negotiated to arrive at 
a workable, yet cumbersome, standard. The geo-science gang are no dummies, 
and have a lot of interest and backing from (earth) mapping authorities, the 
military, GIS vendors and commercial users of geo-data. These players have 
had a LOT mor emoney to throw at the problem than we well-meaning amateurs. 
A lot of hard lessons of been learned. XMLastro could well stand to benefit 
from this experience. One concrete activity could be to review and mine the 
geo-science schemas for useful adaptations for astronomical tasks.

Finally: are we truly convinced that no parallel efforts exist. Sites like 
StarGazersOnline.com offer observation logging and I am sure that there are 
others. Do we have any idea what structures they employ, or any baseline 
against which to compare them for adjusting to future interoperability.

My two cents' worth....

Cheers

_________________________________________________________________
Add photos to your messages with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail

Re: [Xmlastro-discussion] Multiple Objects

[Don W. <don...@ma...>]

>
>
>Perhaps I'm missing the point but whats wrong with simply having:
>
><object> and <objects>
>
>The former being singular and the latter, well, plural
>
Didn't think of that one. Sounds good to me!

>I'd also like different sub-schemas for different categories.  Aurora
>observations gather different data than that obtained for deep-sky. Sounds
>kinda like hard work if you're trying to shoehorn all this lot into a single
>schema.
>
There is only one problem with multiple schemas that I can see. If you 
want the user to validate his/her documents he/she would need to have 
all of the schemas. I don't think it is a big problem, as most users 
will probably use an application which can be bundled with the schemas.

RE: [Xmlastro-discussion] Multiple Objects

[Peter D. <pr...@nt...>]

Perhaps I'm missing the point but whats wrong with simply having:

<object> and <objects>

The former being singular and the latter, well, plural.

I'd also like different sub-schemas for different categories.  Aurora
observations gather different data than that obtained for deep-sky. Sounds
kinda like hard work if you're trying to shoehorn all this lot into a single
schema.

jtm
Peter


-----Original Message-----
From: xml...@li...
[mailto:xml...@li...]On Behalf Of Tom
Wright
Sent: 02 April 2003 15:49
To: XMLastro Discussion
Subject: Re: [Xmlastro-discussion] Multiple Objects


On Wed, 02 Apr 2003 14:24:47 +0200, Don Willems <don...@ma...>
wrote:

>>
>> I like <object-group> better myself. I agree that it seems to convey the
>> intended meaning more accurately than <object-list>.
>>
>
> Do we all agree on this?
> Shall I include it in our schema?
>

Sounds good to me. Tom



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb:
Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Xmlastro-discussion mailing list
Xml...@li...
https://lists.sourceforge.net/lists/listinfo/xmlastro-discussion

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

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

On Wed, 2 Apr 2003 06:05:07 -0500 (EST), Peter C. Chapin 
<pc...@ec...> wrote:

> I'm not familiar with <xs:anyType>.

It is the root of the datatype hierarchy - <element type="xs:anyType"/>.

> I do have a reference that talks about
> the <xs:any> element, however. It gives an example like this:
>
> <xs:element name="XHTMLSection>
> <xs:complexType>
> <xs:sequence>
> <xs:any namespace="http://www.w3.org/1999/xhtml"
> minOccurs="0" maxOccurs="unbounded"
> processContents="skip"/>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> This apparently allows an <XHTMLSection> element to contain any elements
> from XHTML. The processContents attribute controls how the contents of
> that element are validated. The value of "skip" means no validation, but
> other options are possible (namely "strict" and "lax").
>
> Is this the sort of thing we're talking about?

Yes! <xs:any> and <xs:anyAttribute> allow for any content to be extended to 
the schema. The difference with <elem type="xs:anyType"> is that the 
element name is defined and it is only the content of the element itself 
that varies. It works in a similar way to <elem xsi:type=".."> in the 
instance document.

For example:
A schema doc defines weatherType, a complexType instantiated as
<temperature>
  <value units="C">20</value>
  <notes>Roll on summer</notes>
</temperature>
in the namespace http://weather.sourceforge.net

And in the astroXML schema within <observation> the temperature element is 
defined as
<xsd:element name="weather" type="xsd:anyType" minOccurs="0"/>

The instance would then be:

<observation xmlns="http://xmlastro.sourceforge.net"
		        xmlns:w="http://weather.sourceforge.net"
			  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
			  xsi:schemaLocation="xmlastro.sourceforge.net astroxml.xsd
			   			    http://weather.sourceforge.net weather.xsd">

<weather xsi:type="w:weatherType">
	<w:temperature>
		<w:value units="C">20</w:value>
		<w:notes>Roll on summer</notes>
	</w:temperature>
</weather>
			    </observation>

As with <xs:any>, the weather schema is added at instance creation, so 
different content models for weather can be used, with the only difference 
being the element itself <weather> has been defined in the astroXML schema.

> Note that apparently the namespace attribute can be left off so that the
> content of the element can be from any namespace. The reference I have
> even says that this is a nice thing to do during development for exactly
> the reasons we have been discussing. Using this approach does sound good
> and it may be a good way to handle <notes> permanently.

<xs:any> has the advantage of allowing any content, so I agree that during 
development this is probably a better option and more extensible. Using 
<xs:any minOccurs="0" maxOccurs="unbounded" namespace="##any"/>
within the content model for observation we can integrate all the 
additional content models for person, location, weather etc, and then 
decide on naming namespaces at a later date.

But then as we progress, we are probably going to want to tie down the 
content more. The idea behind xs:anyType was to allow an author to define a 
more advanced weather definition than the one we offer by default, without 
interferring with the actual astroXML schema.

Besides, as far as development goes, I was somewhat aghast to discover that 
XMLSpy will validate simpleTypes using the xs:anyType method above but 
*not* complexTypes!! XSV does validate both types.

Tom

Re: [Xmlastro-discussion] Multiple Objects

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

On Wed, 02 Apr 2003 14:24:47 +0200, Don Willems <don...@ma...> 
wrote:

>>
>> I like <object-group> better myself. I agree that it seems to convey the
>> intended meaning more accurately than <object-list>.
>>
>
> Do we all agree on this?
> Shall I include it in our schema?
>

Sounds good to me. Tom

Re: [Xmlastro-discussion] Multiple Objects

[Don W. <don...@ma...>]

>
>
>>I'd prefer the <object-group> element. My feeling is that <object-list>,
>>could contain a list of unrelated objects. The idea is that the objects
>>in the list are related (in position) because you are observing them
>>together.
>>    
>>
>
>I like <object-group> better myself. I agree that it seems to convey the
>intended meaning more accurately than <object-list>.
>

Do we all agree on this?
Shall I include it in our schema?

Don

Re: [Xmlastro-discussion] It's about time.

[Don W. <don...@ma...>]

>
>
> I introduced restricted versions of xs:datetime, xs:date, and
>xs:time to control the time zone option. I feel that observers should
>always include time zone information unless they are specifically
>recording a local time. I provide different elements for local times to
>distinguish them from "absolute" times
>
I don't see that. I would expect timezone information to be included 
specifically with local times (LST).
If you're using LAT or LMT I'd expect geographical information to be 
included.

Anyway I'm not so sure about all these formats.
If I want to include time information of the observation I'd expect at 
least LST or JD and preferrably UTC.
Should we make one of these time formats required and the others LAT, 
LMT,... optional?
For times included in a position LAT or LMT should not even be allowed 
to be included in the time information.
At least that is my opinion.

>It will be common, I think, for a set of observations to occur at
>different times on the same date. Note that the time zone information is
>inherited by the observation as well as the date.
>
I'm sure if we should do this. Timezone information is not that much, so 
it shouldn't be to much of a problem to include it in every local time 
(LST). It will make the information more readable.

>I propose allowing serveral local time forms. I'm not sure how necessary
>that is, but it seems easy so I figured we might as well. Local times do
>not carry any time zone information (nor can they). By definition, time
>zones don't make sense on a local time. Does that sound right?
>
Maybe we should include geographical information?

>The XML Schema time types require quoting times to 1 second precision.
>Obviously that makes no sense in many cases. To deal with that I propose
>adding a "resolution" attribute to our datetime elements to give document
>authors the ability to specify how significant their datetimes are.
>
><datetime resolution="P3H30M">
>  <ISO>2003-03-30T10:00:00-05:00</ISO>
></datetime>
>
>Here a duration of 3h30m is supposed to mean that the actual time is
>between +/-1h45m of the quoted time. I haven't played with xs:duration
>before but I think that's the right format for it.
>
I agree.

>All of this needs to be tested, of course, before putting it into the
>schema officially. However, before going that far... is this the right
>track or am I totally off base?
>
You're on the right track.
I'm not so sure about all those local time formats. If you don't include 
geographical information those times will be meaningless to most 
observers. You cannot calculate the 'absolute' time.
I can see that you might want to include this information though. But 
should it be part of the basic time information which will be included 
in positions and observations?

Don

Re: [Xmlastro-discussion] Multiple Objects

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

On Wed, 2 Apr 2003, Don Willems wrote:

> I'd prefer the <object-group> element. My feeling is that <object-list>,
> could contain a list of unrelated objects. The idea is that the objects
> in the list are related (in position) because you are observing them
> together.

I like <object-group> better myself. I agree that it seems to convey the
intended meaning more accurately than <object-list>.

Peter

Re: [Xmlastro-discussion] notes

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

On Wed, 2 Apr 2003, Don Willems wrote:

> Some time ago we talked about markup within notes like:
>
> <notes>
> 	<p>We started our observation with <object>M 31</object> and ...</p>
> </notes>
>
> It seems that unlike what I initially thought custom tags are allowed in
> xhtml, at least as long as you provide a namespace for these tags. So it
> is possible to use xhtml with our own custom markup elements within the
> notes element.

Is this because of the way XHTML (in v1.1?) is "modularized"? I was
reading a little bit about that recently too but I haven't gotten into it
much yet so I'm not sure exactly what it's all about. If we can indeed
introduce our own markup in XHTML for use in <notes> (and perhaps other
places) that would be very nice, I think.

Peter

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

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

On Wed, 2 Apr 2003, Don Willems wrote:

> > 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?
>
> I favor that, not only for Weather, but also for other types (personal
> information, geographical information, markup for notes, etc...). We
> should though be able to provide the most important information.

I'm not familiar with <xs:anyType>. I do have a reference that talks about
the <xs:any> element, however. It gives an example like this:

<xs:element name="XHTMLSection>
  <xs:complexType>
    <xs:sequence>
      <xs:any namespace="http://www.w3.org/1999/xhtml"
              minOccurs="0" maxOccurs="unbounded"
              processContents="skip"/>
    </xs:sequence>
  </xs:complexType>
</xs:element>

This apparently allows an <XHTMLSection> element to contain any elements
from XHTML. The processContents attribute controls how the contents of
that element are validated. The value of "skip" means no validation, but
other options are possible (namely "strict" and "lax").

Is this the sort of thing we're talking about?

Note that apparently the namespace attribute can be left off so that the
content of the element can be from any namespace. The reference I have
even says that this is a nice thing to do during development for exactly
the reasons we have been discussing. Using this approach does sound good
and it may be a good way to handle <notes> permanently.

Peter

Re: [Xmlastro-discussion] Multiple Objects

[Don W. <don...@ma...>]

> I suggest we avoid the name "object-set" though. It sounds like
> observation-set, yet it works quite differently. Also if one quickly 
> scans
> a document the different <ob.*-set> elements start looking pretty much 
> the
> same. I noticed that when looking at some of the examples you and Tom
> posted. Perhaps <object-group> or <object-list> would be better?

I'd prefer the <object-group> element. My feeling is that 
<object-list>, could contain a list of unrelated objects. The idea is 
that the objects in the list are related (in position) because you are 
observing them together.

Don

[Xmlastro-discussion] notes

[Don W. <don...@ma...>]

Some time ago we talked about markup within notes like:

<notes>
	<p>We started our observation with <object>M 31</object> and ...</p>
</notes>

It seems that unlike what I initially thought custom tags are allowed 
in xhtml, at least as long as you provide a namespace for these tags.
So it is possible to use xhtml with our own custom markup elements 
within the notes element.

Don

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

[Don W. <don...@ma...>]

> 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????

I favor that, not only for Weather, but also for other types (personal 
information, geographical information, markup for notes, etc...). We 
should though be able to provide the most important information.

Don

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

[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