New schema filenames & namespace

[unsp...@knightware.biz]

Dirk mentioned that the file names for the xsd files will need to
change to something OAL-like. We may also want to change the target
namespace for fgca which is currently http://observation.sourceforge.net/comast
- ideas?

- Phyllis

[Tom]

Hi all,

I recently inspected Dirk's proposal for what we called COMAST 2.0
formerly. The namespace and target namespace is just one topic among
many others we have to review and agree upon. I want to put together
what I have found in a (Excel) table so that we can better keep track
of our work. Right now I'm very busy. E&T 3.0 is shipping in the next
days, but I'm out of town next weekend and doing some extra design and
review work for a company project.

Tom

[Tom]

Hi,

here are some comments and ideas on the COMAST 2.0 draft.

Namespace: the targetNamespace as well as "fgca" should be changed.
fgca -> oal, of course. The namespace resembles an URL, but that URL
does not have to be resolveable. So there is no need that we use a
namespace that's existing on the web, too. The reason that real
website URLs are frequently used is because they are unique. We might
use http://observation.sourceforge.net/openastronomylog

The root file (comast20.xsd) does not include base/comastBase.xsd.
This does not matter as all extension xsd files include the
comastBase, but one include on top of the hierarchy should suffice.

comastBase.xsd:
=============

observer.fstOffset has to be clearly defined. Every "offset" refers to
something in the role of a reference. So we need an agreed correlation
between fst and the BSB (background surface brightness). As already
suggested, I suggest using Bradley Schaefer's correlation. Please
check out the Excel file I have uploaded. It compares several data and
suggested correlations. The visual acuity is modelled with a Snellen
term, but this boils down to a simple fst offset. By adjusting the
parameters, you will be able to produce good agreement. Note that the
correlation used by Eye&Telescope shows considerable differences under
brighter skies. I'm aware of this and always planned to improve the
curve here. But I do not observe under such bad conditions often ;-)

The correlation formula I suggest is: fst = 5*(1,586-log(10^((21,568-
BSB)/5)+1)) where BSB is the background surface brightness expressed
in mags / sq. arcsec.. Subtract 2.5*log(3600) to get mags/sq. arcmin
if needed.

If we call the individual deviation of the observer from this standard
correlation an "offset" for me this would obviously mean that it's
given in magnitudes. We can omit the word or concept of the Snellen
ratio. Snellen ratio can be converted to an offset and vice versa, so
it principally does not matter what we use. But an offset is clear and
easy to get for everyone, so it's better.

We have to add an explanatory comment for the element
findingsType.lang

I'm concerned about the measurement units we use for surface
brightnesses. In the deepSkyTargetType the <surfBr> is given in mags
per square arc MINUTE.

So I suggest that we either use the concept of passing the measurement
unit along as an attribute (as we did with the RA / Dec, for instance)
or we consistently use the same unit. I suggest using mags/ square arc
*minute*. Introducing something like a surfaceBrightnessUnit
definition would be overkill! The offset from mags per square arcsec
to ... arcmin is 2.5 * log(3600) = 8.89... This is simple and
sufficient.

So we should rename observation.sqm to observation.backgroundSB (and
avoid to use the measurement unit's name as an element name!). It had
to be given in mags / square arcmin.

ext_DeepSky.xsd:
=============

I'd like to introduce a new target type for Clusters of Galaxies. It
should be derived from the deepSkyTargetType, would be called
deepSkyTargetTypeCG and introduces an optional element named "mag10".
This holds the magnitude of the 10th brightest galaxy in the cluster.
This data is given in catalogs as you can find them in Vizier (CDS
Strasbourg). I thought about adding Abell's richness class in the
first place, but I did not find a good data source with this and
consider it to be of inferior value to an observer.

In findigsDeepSkyType, we should switch from the rating range 1 to 7
to an enumeration: 1,2,3,4,5,6,7 and 99 for unknown. I do not want to
make the rating an optional element because it is one of the most
important parameters for database queries.

I'm looking forward to your comments. Right now, I have not provided
an update to the schema files. I think we should first discuss.

Cheers,
Tom

[Dirk Lehmann]

Hi all,

please see my comments in Toms' post:

Regards

Dirk

P.S.: Sry for the late reply...:-(

On 5 Feb., 12:36, Tom <thomas.pfle...@netcologne.de> wrote:
> Hi,
>
> here are some comments and ideas on the COMAST 2.0 draft.
>
> Namespace: the targetNamespace as well as "fgca" should be changed.
> fgca -> oal, of course.

I Agree

> The namespace resembles an URL, but that URL
> does not have to be resolveable. So there is no need that we use a
> namespace that's existing on the web, too. The reason that real
> website URLs are frequently used is because they are unique. We might
> usehttp://observation.sourceforge.net/openastronomylog

OK for me, too

>
> The root file (comast20.xsd) does not include base/comastBase.xsd.
> This does not matter as all extension xsd files include the
> comastBase, but one include on top of the hierarchy should suffice.

Yep, you're right

>
> comastBase.xsd:
> =============
>
> observer.fstOffset has to be clearly defined. Every "offset" refers to
> something in the role of a reference. So we need an agreed correlation
> between fst and the BSB (background surface brightness). As already
> suggested, I suggest using Bradley Schaefer's correlation. Please
> check out the Excel file I have uploaded. It compares several data and
> suggested correlations. The visual acuity is modelled with a Snellen
> term, but this boils down to a simple fst offset. By adjusting the
> parameters, you will be able to produce good agreement. Note that the
> correlation used by Eye&Telescope shows considerable differences under
> brighter skies. I'm aware of this and always planned to improve the
> curve here. But I do not observe under such bad conditions often ;-)
>
> The correlation formula I suggest is: fst = 5*(1,586-log(10^((21,568-
> BSB)/5)+1)) where BSB is the background surface brightness expressed
> in mags / sq. arcsec.. Subtract 2.5*log(3600) to get mags/sq. arcmin
> if needed.
>
> If we call the individual deviation of the observer from this standard
> correlation an "offset" for me this would obviously mean that it's
> given in magnitudes. We can omit the word or concept of the Snellen
> ratio. Snellen ratio can be converted to an offset and vice versa, so
> it principally does not matter what we use. But an offset is clear and
> easy to get for everyone, so it's better.
>

Well to be honest. I'm not deep enough into that whole fst/BSB/sqm
stuff,
but I think we should make it as simple as it could be. So your offset
suggestion is fine for me...

> We have to add an explanatory comment for the element
> findingsType.lang

You mean that session.lang should be the taken in case finding.lang
doesn't exist. And if both exist, finding.lang is dominant?
Ok for me.

>
> I'm concerned about the measurement units we use for surface
> brightnesses. In the deepSkyTargetType the <surfBr> is given in mags
> per square arc MINUTE.
>
> So I suggest that we either use the concept of passing the measurement
> unit along as an attribute (as we did with the RA / Dec, for instance)
> or we consistently use the same unit. I suggest using mags/ square arc
> *minute*. Introducing something like a surfaceBrightnessUnit
> definition would be overkill! The offset from mags per square arcsec
> to ... arcmin is 2.5 * log(3600) = 8.89... This is simple and
> sufficient.

I think giving the unit as attribute is the best way for beeing
flexible enough in the future...

>
> So we should rename observation.sqm to observation.backgroundSB (and
> avoid to use the measurement unit's name as an element name!). It had
> to be given in mags / square arcmin.

I agree

>
> ext_DeepSky.xsd:
> =============
>
> I'd like to introduce a new target type for Clusters of Galaxies. It
> should be derived from the deepSkyTargetType, would be called
> deepSkyTargetTypeCG and introduces an optional element named "mag10".
> This holds the magnitude of the 10th brightest galaxy in the cluster.
> This data is given in catalogs as you can find them in Vizier (CDS
> Strasbourg). I thought about adding Abell's richness class in the
> first place, but I did not find a good data source with this and
> consider it to be of inferior value to an observer.

Sounds good!

>
> In findigsDeepSkyType, we should switch from the rating range 1 to 7
> to an enumeration: 1,2,3,4,5,6,7 and 99 for unknown. I do not want to
> make the rating an optional element because it is one of the most
> important parameters for database queries.

OK for me, too

[Tom]

Hi all,

we need to agree upon a BSB <--> fst correlation that should be the
reference for our observer's offset.

I have compared the proposed correlation by Schaefer (see the Excel
file I have uploaded) with an analysis of "Sky At Night" data
conducted by Andreas Haenel, a German dark sky activist. I feel that
Schaefer's correlation is closer to Haenels analysis than is my own
E&T correlation. Therefore I vote to agree upon the Schaefer
correlation. If we cannot agree, we are stuck at this point and had to
omit the offset from the Schema. Personally, I would regret this.

E&T 3.0 had a rather successful rollout, so after solving the first
issues I now have a bit more time to pick up the <OAL> theme once
again. The next action will be to implement an export according to the
proposal so that we have at least one comprehensive OAL 2.0 compliant
file for testing the import. What do you think?

@Phyllis: meanwhile a DVD with E&T 3.0 I sent out to a Colorado
address has arrived there. So I hope that you will receive your
package soon.

Cheers,
Tom

[Phyllis]

All,

I haven't had a chance to study the proposal yet, but I should be able
to get back to it shortly.

@Tom, no DVD yet. I will certainly let you know when it arrives. The
last CD I sent to Germany took a month. The previous one took a
week. Makes no sense!

- Phyllis

[Dirk Lehmann]

Hi Tom,

to be honest I didn't digg very deep into this but the mentioned
Schaefer
correlation makes sense for me, too.

Best
Dirk

[Tom]

Hi all,

I have worked on our OAL 2.0 Schema proposal. The modifications we
have discussed are done. I have added comments where appropriate.

One obvious change was to switch from comast20.xsd to oal20.xs. I did
this to really get rid of all legacy terms and acronyms.

Having started the implementation of the new schema version in E&T, I
realized how much work here and there this will require. Currently I
do not have sample documents but soon there will be some.

Please see the files section for the latest refinement. I hope that we
can agree upon this to become our "2.0".

Best wishes,
Tom

[Dirk Lehmann]

Hi Tom,

thanks for your work. Looks good for me!

However, even if we all agree on this proposal, I would like to
propose to wait with its release until at least 1 or 2 projects have
finished their implementation,
as history showed, we're really digging deep into the schema and find
some moew bugs/flaws once we implement it.

Best regards

Dirk

P.S.: I change the welcome page of the group to incorporate our new
logo. Hope you like it... :-)
Also the "Applications supporting <OAL>" page was edited by me. Hope
this fits...

[Tom]

Hi Dirk and all others,

> However, even if we all agree on this proposal, I would like to
> propose to wait with its release until at least 1 or 2 projects have
> finished their implementation,
> as history showed, we're really digging deep into the schema and find

> some more bugs/flaws once we implement it.
>
That's perfectly OK for me. I'll work on it, but cannot tell you how
fast progress will be. Some extensions will require extensive testing.
Maybe that I'll be even forced to retract the "fst <--> SQM plus
individual offset" suggestion if it turns out that it simply does not
yield reasonable results in the prediction of perceptability. If it
doesn't really work, we should perhaps dispose of this idea.

The big question for me is how to deal with backward compatibility.
Should I provide 1.7 import capability or not? We both will offer free
updates to versions supporting 2.0 import. As beside OM and E&T there
are currently no other applications that generate 1.x documents, this
seems practicable for me. 2.0 is the "synchronizing version" where we
expect all implementing applications to come together. I hope that
Deep Sky Planner and deepskylog.org can arrange with this. Please tell
us if you have any concerns.

Best wishes,
Tom

[Dirk Lehmann]

Hi,

regarding the backward compatibility this is fine for me. OM will be
able to import 1.x files and will always export 2.0 files as of 0.820.
On 0.820, I'm currently unsure when this will be made available. I've
already implemented most of the 2.0 changes, but there's still quiet
some stuff to do (incl. the new name)...

Best regards

Dirk

[Phyllis]

All,

I have been planning to support OAL starting with schema v2.0. The
work I did several months ago on this served as a proof of concept for
Deep-Sky Planner. Import and export using the base schema were working
well at that point. I stopped development at that time while waiting
for the remaining details to settle.

I'll need to revisit my code and the latest changes to the schema to
be sure that I'm still good to go.

Thanks to everyone for their participation!
- Phyllis

[Tom]

Hi all,

there have been occasional requests for E&T to cover astrophotographic
logging information. I do not plan to support this in the near future
- as a photography greenhorn I definitely lack any required knowledge.
But I think that we should not block the way for volunteers to expand
the standard to cover photo logging.

Currently we have a rudimentary <imager> definition. I'm pretty sure
that this will have to be expanded as soon as someone looks seriously
on it. To separate concerns, I'd like to see the <imager> definition
in a separate XSD file that can hold photographic findings or image /
processing parameters some day - when required. Just as we separate
deep sky, solar system and variable star observations, future
photographic observations should use their own, distinct extension.

It's the right time to decide upon and execute such a change. When we
release new versions of our clients, it's too late!

Please comment!

Cheers,
Tom

[Dirk Lehmann]

Hi all,

what about stripping the imagerType element down to only the unique
ID, vendor and model. And using this as a base element all other
imagers must derive from.
The derived CCDImager element would move out into a separate schema
file.

With that we would have a general anchor in the base schema for all
kind of imagers, and we don't need
to create a dependecy from the base.xsd to some extension xsd. (As
observations element requires some
basic knowledge on imagers and that basic description should be held
in the base.xsd IMHO)

Best regards

Dirk

[Tom]

> what about stripping the imagerType element down to only the unique
> ID, vendor and model. And using this as a base element all other
> imagers must derive from.
> The derived CCDImager element would move out into a separate schema
> file.
>

Sound very reasonable for me. But let's wait for further comments.

Best regards,
Tom

[Tom]

Hi all,

On 6 Mai, 11:10, Dirk Lehmann <doe...@gmx.de> wrote:
> Hi all,
>
> what about stripping the imagerType element down to only the unique
> ID, vendor and model. And using this as a base element all other
> imagers must derive from.
> The derived CCDImager element would move out into a separate schema
> file.
>
> With that we would have a general anchor in the base schema for all
> kind of imagers, and we don't need

> to create a dependency from the base.xsd to some extension xsd. (As

> observations element requires some
> basic knowledge on imagers and that basic description should be held
> in the base.xsd IMHO)
>
> Best regards
>
> Dirk
>

Before uploading my recent changes, I first have to go through some
tests. Here is a description of what I changed:

* Modified imagerType:

<!--Describes the imaging device used in an observation. This type
may be extended to capture information on different sensor
technologies.-->
<!-- New in V2.0: this type is now abstract. Concrete imagers are
extending the definition, using the ext_imaging schema file. -->
<xsd:complexType name="imagerType" abstract="true">
<xsd:sequence>
<!-- model or designation -->
<xsd:element name="model" type="xsd:string"/>
<!-- New in V2.0: 'type' element removed: concrete imagers are
extending this type definition in the ext_imaging extension -->
<xsd:element name="vendor" type="xsd:string" minOccurs="0"/>
<xsd:element name="remarks" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:ID" use="required"/>
</xsd:complexType>

There is a new extension called ext_Imaging.xsd with the derived CCD
camera type:

<!--An extension of the imagerType to describe CCD cameras-->
<xsd:complexType name="ccdCameraType">
<xsd:complexContent>
<xsd:extension base="oal:imagerType">
<xsd:sequence>
<xsd:element name="pixelsX" type="xsd:positiveInteger"/>
<xsd:element name="pixelsY" type="xsd:positiveInteger"/>
<!-- New in V2.0: Pixel size in microns -->
<xsd:element name="pixelXSize" type="oal:positiveDecimal"
minOccurs="0"/>
<xsd:element name="pixelYSize"
type="oal:positiveDecimal" minOccurs="0"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>

If there where "photographical findings" some day including exposure
times, filter usage, binning settings, darkframe / flatfield data,
descriptions of image processing tools and techniques, ... this would
also go in this extension.

I have already implemented the Clusters of Galaxies in E&T and
realized that their <mag10> element is not practical. This is the
magnitude of the 10th brightest member of the cluster. I decided to
discard this element and use the <visMag> of the deepSkyTargetType to
store this data. At first this may look like a modelling flaw, but is
has a simple practical advantage: you may easily consider CGs when
filtering for objects with a user defined limiting magnitude. So a
typical object database SQL query does not have to join a details
table for the magnitude of CGs, but use the common magnitude column
for all objects. Given this, the CG definition shrinks down to
triviality:

<!-- New in Version 2.0 -->
<!-- type definition for clusters of galaxies -->
<xsd:complexType name="deepSkyCG">
<xsd:complexContent>
<xsd:extension base="oal:deepSkyTargetType"/>
<!-- For Clusters of Galaxies, the *magnitude of the 10th brightest
member* is given -->
<!-- in the <visMag> element of the deepSkyTargetType -->
</xsd:complexContent>
</xsd:complexType>

Then I came across *notes* of the observation targets. We have talked
about before, but just forgot them. Fixing this, I have inserted the
<notes> element after the optional <constellation>:

<!-- type definition for arbitrary observation targets -->
<xsd:complexType name="observationTargetType">
<xsd:sequence>
<xsd:choice>
<!-- identification of data source -->
<xsd:element name="datasource" type="xsd:string"/>
<!-- used for targets not listed in standard catalogs; f.e. newly
discovered objects -->
<xsd:element name="observer" type="xsd:IDREF"/>
</xsd:choice>
<!-- most common name -->
<xsd:element name="name" type="xsd:string"/>
<!-- alternative names -->
<xsd:element name="alias" type="xsd:string" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:element name="position" type="oal:equPosType" minOccurs="0"/>
<!-- constellation is optional because it can be derived from
position -->
<xsd:element name="constellation" type="xsd:string" minOccurs="0"/>
<!-- New in V 2.0: notes on targets -->
<xsd:element name="notes" type="xsd:string" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:ID" use="required"/>
</xsd:complexType>

When importing, an application has to decide how to deal with
differences between existent notes and the notes to be imported. Some
cases are straightforward:
* If we do not have notes, import the ones from the file
* If the file's notes are empty, do nothing to the existent notes
* If there are notes in stock and the notes to be imported are the
same, do nothing

And now it becomes interesting:
* If there are notes in stock and the notes to be imported are
different, let the user decide what to do. Possible options are: keep
existing, replace existing, or merge (append or prepend, insert a
comment). Looking closer on this, it seems a bit complicated. While
this "notes conflicts handling" is not a core task of our schema work,
it seems reasonable to me to give some advice on this topic in a
future "Programmer's Guide". All applications using a database to
persist target data will have to answer this question - if they
support target notes at all.

I also reordered some of the type definitions. While editing, I
suddenly had the feeling that this was due as definitions did not
follow up in any order related to anything... That had to be tidied up
a bit.

Best wishes,
Tom

[Dirk Lehmann]

Hi Tom,

thanks for the update!
Looks good from my point of view.

Best regards

Dirk

[Wim De Meester]

Hi all,

I played a little bit with the latest scheme which can be found on the website. I adapted DeepskyLog to export a OAL 2.0 file. I've attached this file to this mail.

Can someone look into this file to see if I have a correct OAL 2.0 file?

I have some problems with the headers... I use the following headers in my export, but I don't know whether these headers are correct...

<oal:observations xmlns:oal="http://observation.sourceforge.net/openastronomylog" version="2.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://observation.sourceforge.net/openastronomylog oal20.xsd">

I'll try to adapt the OAL import to support version 2.0 as soon as possible.

Cheers,

Wim

>

--

Wim De Meester

Katholieke Universiteit Leuven

Instituut voor sterrenkunde tel: +32 (0)16 327914

Celestijnenlaan 200 D fax: +32 (0)16 327999

B - 3001 Leuven email: wim.de...@ster.kuleuven.be

Belgium http://www.ster.kuleuven.be/~wim

[Phyllis]

Wim,

The first few lines of your file look this for me in Stylus Studio
(see below.) It looks like there is an encoding problem with the
equals character being written as '=3D'. and lines are being truncated
at column 76.

Hope this helps!
- Phyllis

<?xml version=3D"1.0" encoding=3D"ISO-8859-1"?>
<oal:observations xmlns:oal=3D"http://observation.sourceforge.net/
openastro=
nomylog" version=3D"2.0" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-
inst=
ance" xsi:schemaLocation=3D"http://observation.sourceforge.net/
openastronom=
ylog oal20.xsd">
<observers>
<observer id=3D"usr_wim" >

[Phyllis]

Tom (et al),

It's taken all day to get to it, but I'm looking at your proposed
schema and thinking about the changes you described.

1) ext_Imaging.xsd
Would you expect that other imager types would be added to this file
in the future, or would other extension files be added for new camera
types? The current definition can already accommodate dedicated CCD
cameras, DSLRs and webcams, but it's not quite appropriate for film.
If we want to add film camera in the future for example, we could add
another type to the existing extension file and bump the version.
Alternatively, we might add another extension file that defines a film
camera. If we choose the latter, the only concern I have is with the
*name* of the current extension file. It might need to indicate CCD
based cameras if we intend to add future camera definitions to a
different extension xsd.

2) You mentioned photo findings and a binning element. I feel like
binning should be an element in the imager type because it determines
image scale for the optical system. That seems different to me than
processing and exposure data. If you have real trouble with putting
binning into the imagerType, then I can live with that. If you agree
that binning go with the imagerType, now would be the time to add it.
I would suggest something like this for a binning element:

<xsd:element name="binning" default="1">
<xsd:simpleType>
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="1"/>
<xsd:maxInclusive value="3"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:element>

I'll try to have a look at galaxy clusters in the ext_DeepSky schema
tomorrow morning and get back to you then.

Thanks to all for your efforts,
- Phyllis

[Wim De Meester]

That's probably a problem with the encoding of the mail... I'll have a look at it.

Wim

>

--

[Tom]

Hi all,

Yesterday I could proceed with the implementation of OAL2.0.

Yesterday I suggested to use the base types <visMag> to store the
tenth brightest member magnitude in a Cluster Of Galaxies. I
implemented it this way and (as explained) this enables E&T to filter
on that property. However, having both a diameter and a magnitude for
a CG, E&T derives a surface brightness and displays a contrast above
threshold in some lists what is - as I now see - complete nonsense.
What a silly whim! Of course this is an abuse of a schema element,
fooling up a clear model. So I just restored the <mag10> element in
the deepSkyCG definition. This is clear and I can explain it without
being on risk for any misinterpretation.

Imagers and fotografic findings: I'm not going into this, at least not
in the next two or three years. I have no opinion in this point and
not the expertise or will to discuss this here, at least not for the
moment. As a non-photographer I just lack competence to contribute
anything practically proven here. But albeit, one thought on this: I
understand our extension concept in a way that an application chooses
what extensions to implement, but should try to implement supported
extensions as completely as possible. My opinion therefore is that an
application supporting the imaging extension should ideally deal with
all types of cameras to be defined within - be it CCD, film or some
new, obscure technology. Omissions have to be documented so that users
can see what data they might loss when transporting XMLs from one app
to another. The need to document omissions in the supported extensions
should go into our Compliance Guidelines (I have not checked these
whether that's already in there).

To support our common efforts, I'll soon provide a E&T 3.1 beta with
support for our "working draft" and some exports created from my log.
The observer's fst offset and Schaefer formula will take some time to
implement and validate, so the beta will probably come without this
(important!) details. I have to find out how using Schaefer's formula
influences the CAT predictions if it is used instead of the empirical
correlation used now. If there are discrepancies, I'll probably keep
the proven correlation and use the Schaefer formula only to convert
between fst and SQM values when entering observations or for export/
import. But whatever I'll find out here will *not* affect the
schema :-)

The latest version of OAL2.0 is updated in the files section. That's
the one we should agree upon soon. IMO we should try to have OAL2.0
compatible versions of our software by July or August. It was great if
we could release the "platform" during one day or week, also reporting
about this in astronomy forums.

@Wim: do you see any chance having a "test and acceptance" version of
deepskylog.org available? Phyllis, Dirk and I could use this to test
uploading observations and see whether we can import from the web app.
Unless all three apps do not perform well in both directions, our task
is not done ;-) Following developers like Paul Rodman would also
benefit from having a web app with test data to develop against! IMO a
full clone of the deepskylog treasure of observations is not necessary
in the test environment. Just the new software release and an empty
database should suffice for starting out. The test environment IMO
wouldn't require special protection, the usual accounts are enough.
But it might be a good idea to keep the URL confidential (=not linked
anywhere to avoid detection by robots!) and to pass it on by personal
mail only to registered members of this group.

Thanks for your excellent collaboration!
Tom

[Wim De Meester]

Hi all,

I will set up a test server for DeepskyLog when the import is also updated to OAL version 2.0.

Cheers,

Wim

>

--

[Tom]

Hi all,

the ext_deepSky.xsd was invalid (a wrong extension tag in deepSykCG).
I have fixed this and updated the oal20_proposal_final.zip.

Cheers,
Tom

[Phyllis]

All,

I received no comment on last week's proposed addition of a binning
element to the ccdImagerType definition found in ext_Imaging.xsd, so I
have uploaded a revised oal20_proposal_20May.zip that includes this
change. I don' think it will break anyone's code as it has a default
value indicating of 1x1.

Thanks,
Phyllis

[Tom]

Hi all,

I have uploaded a new version of the schema. The filter definition
lacked a <vendor> element, while the other optical gadgets alredy had
theirs.

Of course I did not touch Phyllis latest imagers modification. To
avoid confusing in our files area, I discarded the former (older)
drafts.

The files section now holds a new OAL2.0 sample file to test your
import routines. I covers (at least I hope so) all deep sky object
types and containts examples of a zoom eyepiece, naked eye
observations, observations with (color) filters, with and without
sessions and much more. In the solar system, there are observations of
comets, minor planets and planets. I did not give samples for sun and
moon, however. The sample file holds one (artificial) observation of a
multiple star.

The sample file does cover neither imaging nor varibale stars,
however. Maybe someone volunteers to add so test entries for these?

Best wishes,
Tom

[Tom]

Hi all,

I'm back from my holiday. During the last weeks without internet
access, I could take some time to work on the OAL2.0 implementation in
E&T. While doing this, I found our OAL2.0 working draft so mature that
I want to propose to accept it as an official release.

From my E&T point of view, the next update with OAL2.0 compatibility
is ready. I have to document the new features and do further tests,
but a release should be ready in September.

Please comment, maybe with some information about the current state of
your projects.

Best wishes,
Tom

[Dirk Lehmann]

Hi Tom, all

my family an I are currently moving into our new house, which means
I've currently
no time for some more work on OM 0.820 which will include <OAL> 2.0
support.
(as a matter of fact I'm still missing (since ~4 weeks) an internet
connection at home *sigh*)

However before the movement I was able to finish some work on 2.0
support as well as new 0.8 features on OM, but
the latest changes we discussed here aren't reflected, yet.
So from my current point of view <OAL> 2.0 looks quiet good. Nothing
to add from my side.

I hope I can be again more responsive once I get rid of all these
boxes in my house ;-)

Best regards

Dirk

[Phyllis]

Hi All,

I'm writing unit tests now for data import and export. I will be
updating my code and unit tests for OAL2.0 changes in the next few
weeks. That should give me a chance to identify any problem I
encounter within that time frame.

@Dirk can I have your boxes? Just kidding - my oldest is heading away
to university in 2 weeks. Busy times!

- Phyllis