Extension request: links for a session

[Tom]

Hi all,

my recent development brought the idea to extend our schema with an
optional element of the session to attach images. For the observation
this already exists. So it's about this suggestion:

<!-- common remarks or conditions of observations conducted during
one night/session -->
<xsd:complexType name="sessionType">
<xsd:sequence>
<!-- Start of observation session -->
<xsd:element name="begin" type="xsd:dateTime"/>
<!-- End of observation session -->
<xsd:element name="end" type="xsd:dateTime"/>
<!-- site where session took place -->
<xsd:element name="site" type="xsd:IDREF"/>
<!-- WHO participated in the observation session? -->
<xsd:element name="coObserver" type="xsd:IDREF" minOccurs="0"
maxOccurs="unbounded"/>
<!-- Comments about the weather situation -->
<xsd:element name="weather" type="xsd:string" minOccurs="0"/>
<!-- Comments on the (optical or electronical) equipment used -->
<xsd:element name="equipment" type="xsd:string" minOccurs="0"/>
<!-- Any other comments -->
<xsd:element name="comments" type="xsd:string" minOccurs="0"/>
<!-- V2.1: references image files obtained in the session -->
<xsd:element name="image" type="xsd:string" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
<xsd:attribute name="id" type="xsd:ID" use="required"/>
<xsd:attribute name="lang" type="xsd:string" use="optional"/>
</xsd:complexType>

What do you think? I'd happy if you agree with it. I'd like to have a
new version of our schema for the next update to Eye&Telescope (that
otherwise only brings new features not related to OAL).

Aside of this, I hope that you all are doing well! Our group became
quite silent, but no wonder - we have a stable, proven solution and
obviously there is not much demand for new features.

Best wishes,
Tom

[Phyllis]

Hi Tom,

Since the element is optional, it certainly won't break existing code
(good)! But, how does one use the new field? Are there some implied
rules for a string that describes images for a session?

Best,
- Phyllis

[Wim De Meester]

Hi Tom,

This is fine for me. We just released a DeepskyLog version where the OAL
sessions are implemented.

Cheers,

Wim

[Dirk Lehmann]

Hi Tom,

sorry for the late reply.
Fine for me, too.
Would those images contain views of the session itself, meaning non astro-images or what should be the intented use case?

Best

Dirk

2011/7/11 Tom <thomas....@netcologne.de>

--
You received this message because you are subscribed to the Google Groups "openastronomylog" group.
To post to this group, send email to openastr...@googlegroups.com.
To unsubscribe from this group, send email to openastronomyl...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/openastronomylog?hl=en.

[Tom]

Hi all,

thanks for your replies.

@Dirk: I think of downloaded weather satellite images, a panorama of a
new site, a map to find a site, a group picture of happy observers or
a simple astro photo like a wide field Milky Way shot. Probably there
are much more useful options for images to accompany sessions.

From a technical point of view, an images container allows for
rendering the images attached to a session when we transform/export a
list of observations. I just missed this. For targets, we have images
in an export from our XSLTs, but not for the session.

@Phyllis: I remember that we once came to the conclusion that handling
links or images is an application specific task. For XSLT, an image
link must but something relative to the root of the generated
document. Just like a web application gives all path relative to its
*context path*.
In Eye&Telescope, there are root directories for planning documents
and for links. They can be set by the users according to their needs.
When a link/image has been attached and is about to be stored, the
code determines whether the file is somewhere below the root or in a
different directory. In the first case, a relative path is built and
stored. Otherwise, an absolute path (with drive letter) is stored. The
difference is obvious: an absolute path is fragile; on another machine
it probably won't work. The relative path will work, provided the
linked file is also on the other machine, in the same relative
position to a potentially other root directory.

All this logic is already there in E&T for links on targets and links
on single observations. When a broken link is found after an import,
the user is prompted to discard the link(s) or he can relocate the
root to make the links work again.

@Wim: I took a look at this, nice thing!

How to proceed? I suggest that we issue a new 2.1 version, with the
session modified as suggested above. Before we do this, please take
your time and think whether there are further topics we could/should
address. I'm not in a hurry and I suggest that we do not issue updates
too often. What about the end of July for this turn?

Tom

[Tom]

Hi all,

I have uploaded the new OAL 2.1 Schema in our Google Code OAL project.
As announced, there are no changes beside the introduction of the
<image> children for a <session>.

To assure downward compatibility, U have attached a transform to
convert an OAL 2.1 document into OAL 2.0. This is trivial, of course.
But otherwise the applications might be broken that are not yet ready
to consume OAL 2.1.

Tom

[Dirk Lehmann]

Hi Tom,

thanks for the upload (btw. heres the direct link to our Google code site: http://code.google.com/p/openastronomylog/).
Looks fine for me. Shouldn't be that much work for next OM...

Best

Dirk