[Xena-devel] Xena improvements now in sf.net RFE tracker

[Simon D. <si...@na...>]

You may remember that early last month I posted the email below to the ator
discuss group, documenting some changes Chris and I agreed to make to Xena
when I was last in Canberra.

Today, I added these changes to the Requests For Enhancements tracker at
sf.net:

- Request ID 930828 relates (in part) to #2 below
- Request ID 930837 relates (in part) to #2 below 
- Request ID 930838 relates to #1 below

I haven't added a RFE for #3 because there are still some unresolved issues
with this one! In each case, the wording ofr the RFE doesn't exactly match
the wording below.

There are obviously many other functional requests either explicitly or
implicitly stated in ator, xena-devel, or xanadu-devel emails. There are
also many requests that have never been documented but have just been added
to Xena (mostly because Chris B and I have just agreed to a change at a
face-to-face meeting). It is my hope that all of these requests will end up
in the RFE tracker mechanism.

For my part, I don't see the RFE tracker as anything other than a great big
in-box of ideas about what Xena could/should do. The functional spec is
where the actual requirements for Xena live. My hope is that, in the future,
stuff will get into the functional spec via the RFE tracker mechanism.

If you have any requests that you want to make please add them to the RFE
mechanism! This is important because we have grown quite a bit from the
early days of development when decisions could be easily made by Chris and
myself at a whiteboard. Do people have any ideas about what Xena should do?

Simon

-----Original Message-----
From: Simon Davis 
Sent: Thursday, March 04, 2004 11:37 AM
To: 'at...@na...'
Subject: Xena improvements


Chris B and I agreed to some improvements to Xena after the project team
meeting on Tuesday. These will be implemented in Xena in time for May (they
haven't yet been added to the Functional Requirements for Version 1.0
document).

1. emailmessage View
At the moment there isn't a View specifically for emailmessages: if you open
an emailmessage instance, it appears as Raw XML only. We created a mockup
for how the emailmessage View should be, see the attached image.

2. 'Basic' View for XHTML and Open Office XML
At the moment views for XHTML and Open Office XML are provided by the end
user's web browser or OpenOffice.org respectively. This is great because
these tools provide a very sophisticated view of the document instance. But
it isn't too great if you don't have a web browser or OpenOffice.org
integrated into Xena. So we decided to provide a 'basic' View of XHTML and
Open Office XML from within Xena that means these instances are always
accessible, even if the user doesn't have any other application software.
The basic XHTML view will be provided by the Swing-supplied HTML widget
(this provides capability for most HTML 3.2 features). The basic Open Office
XML view will be based on the simple OpenOfficeViewer I created last year
and posted to at...@na... (this code will, however, need some work!)
A XHTML or Open Office XML document instance will open into the appropriate
basic view. It will then be possible for a user to select a 'Change View'
option to view the instance with their web browser or OpenOffice.org
installation.

3. Representing the source of a package in embedded metadata
As a result of previous discussions about using dc:source to show both the
relationship between packages within the repository and the original
structure of the directory tree of a transfer job, dc:source in a Xena
package could hold one of two types of information: a file pathname or a
package identifier. We agreed that this overloading of the dc:source element
wasn't appropriate because it will make processing much more difficult and
potentially confusing.
There needs to be some distinction in the XML markup between a file pathname
source and a package identifier source. 
The way this markup distinction is implemented hasn't been decided. Our
preferred option is to add an attribute to dc:source that indicates the
scheme of the identifier. Speaking to Andrew, it seems like we can't do
this: I'm going to do some investigation on dublincore.org to confirm. If we
can't use an attribute, our second position is to use different elements for
a package identifier source and a file pathname source.

Simon