Project

General

Profile

Bug #553

support eml 2.0.0 and later revisions

Added by Matt Jones almost 19 years ago. Updated over 17 years ago.

Status:
Resolved
Priority:
Immediate
Category:
morpho - general
Target version:
Start date:
07/09/2002
Due date:
% Done:

0%

Estimated time:
Bugzilla-Id:
553

Description

Morpho current supports EML 2.0.0beta6. The substantial changes in beta9 will
require some reworking of packaging concepts in morpho among other things. We
should plan on accomodating this new release as early as possible, but its
proably realistic to include it as part of the capabilities enabled by the new
Jalam project form generator. Comments?


Related issues

Blocked by Morpho - Bug #289: Problem with Morpho handling DTD entity declarationsResolved10/02/2001

Blocked by Morpho - Bug #88: need ability to manipulate access control listsResolved08/20/2000

Blocked by Morpho - Bug #354: User input column(Attribute) data typesResolved11/30/2001

Blocked by Morpho - Bug #374: dtd parser cannot handle multi-rooted dtdsResolved12/16/2001

History

#1 Updated by Matthew Brooke almost 19 years ago

If I understand correctly, the issue of enabling Beta-9 functionality in Morpho
involves two major areas - one being the "front-end" forms view, and the other
being the "behind the scenes" functionality that takes care of assembling and
renumbering package versions, talking to Metacat, etc etc.

I think that the part of Jalama that deals with form generation would be
well-suited to creating the front end, but I think that architecturally, the
resulting forms should have little or no knowledge of the back-end functionality
- so they can reveive and send data to the Morpho classes for organization and
upload (i.e. we should maintain a clear deliniation between the two. Comments?

#2 Updated by Matt Jones almost 19 years ago

Matthew,

Yes, I agree with your basic approach of encapsulating responsibility
indifferent components. However, the Jalama project has as one of its own goals
the encapsulaton of at least 3 distinct layers of functionality:
1) schema handling
2) layout and presentation (ui controls and placement)
3) application logic (ui flow and other application needs)
So, I think that (1) should cover the idea that data can be read in from and
written out to arbitrary schemas from within the Jalama products. But I agree
that this should be a distinctly separate layer of functionality from the user
interface layout, and the user interface behaviors and application logic.

That said, I agree with your point that Morpho and not Jalama should deal with
the logistics of writing data to disk or metacat, or other management of the
data outside of editing it. In other words, Morpho should read a stream of data
in an arbitrary schema from Metacat or the file system, pass it to Jalama with
an indication of the configuration info needed for Jalama (style sheets, etc),
and then Jalama will pass back an edited data product that complies with the
appropriate schema, which Morpho will send off to Metacat or whatever it wants.
The hard part is figuring out how to deal with complex schemas that utilize
multiple entities (e.g., more than one table, or more than one xml document),
but I think this is a critical component of Jalama.

So, you're not off the hook yet...

#3 Updated by Dan Higgins over 17 years ago

Morpho now uses eml 2.0.0 so this bug is no longer applicable.

#4 Updated by Redmine Admin about 8 years ago

Original Bugzilla ID was 553

Also available in: Atom PDF