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