I've attached this schema just so that everyone has a chance to see one option
for eml.xsd. the assumptions made by this approach is that each module contains
a base complex type that defines ALL the content for that module. All modules
are included into the main schema (named datasetMerged here). a local element
is created, set to extend one of the imported complex types, and then extended
with other elements (either optional or repeating) that are in turn typed as
other imported element types, and so on down the line.
This solution preserves the integrity of the individual modules but of course
requires us to re-release a new eml.xsd each time we want to accomodate a new
module. It does not solve ALL problems - but it does work well for those
linkages that we want to handle by nesting (which i think sould be the
preferred way). To address other problems i would consider:
1) settling on either id-idref or required name elements as the method of
relational pointing for situations where it cant be avoided (connections,
foriegnKeys, etc)
2) for each major element that extends an imported complex type, add an
optional, repeateable ANY element to allow non-eml content to be nested pretty
much anywhere the user thinks its appropriate.
3) consider retaining the triple or xpointer for continued support for external
referencing.
This is still a pretty big issue - we might want to consider a conference call
to check where everyone's thinking is.