[DDI-SRG] Schema module imports

[Joachim Wackerow]

Arofan,

I think every "larger" module makes sense as stand-alone. So each larger 
bunch of information can validated for its own (for references it is 
only possible just with internal references). I see the following 
modules as candidates:

archive
comparative
conceptualcomponent
datacollection
group
logicalproduct
physicaldataproduct and all substitution modules
ncube_recordlayout
tabular_ncube_recordlayout
inline_ncube_recordlayout
dataset
physicalinstance
studyunit

Some form of loose hierarchy exist in the module structure: the 
instance, modules at instance level and modules only possible in 
studyunit, group, resourcepackage. Each higher level module doesn't need 
  to import modules which are already imported at an lower level. This 
form of bottom-up approach must be surely reviewed in detail. Below are 
some thoughts based on that.

xml is imported in reusable and reusable is used everywhere. So it 
probably must be imported only in reusable. reusable must be perhaps 
just imported only in the "lower" stand-alone modules, which comprehends 
everything from the list above without group, studyunit, and the new 
resourcepackage.

Achim

Wendy Thomas wrote:
> As I recall we talked about Group only importing StudyUnit and Comparative 
> because we were going to make a separate ResourcePackage that would allow 
> packaging reusable resources.
> 
> Wendy
> 
> 
> On Thu, 3 Jan 2008, arofan.gregory wrote:
> 
>> Folks:
>>
>> Here is a breakdown of the imports in the current (CR2a) draft of the
>> schemas.
>>
>> I will try to come up with a set of suggested changes, but I will note a few
>> issues here:
>>
>> - xml.xsd is imported into too many schemas. This is messy and not needed.
>>
>> - We know that there are issues with dataset, as Achim has identified.
>>
>> - It seems like there is some random/inconsistent importing going on. We
>> need to decide which modules can be instantiated as stand-alones, and then
>> remove some of the imports. Note that everything which is non-end-node (such
>> as dcelements and xml.xsd) imports the resuseable.xsd schema. Also, merging
>> archive.xsd and organization.xsd removes much of the messiness and
>> inconsistency.
>>
>> It would be possible to have everything always exist inside a DDIInstance
>> element, and we could simply import everything at that level and not worry
>> about it. This may be a bit draconian, but if we do anything else we will
>> need to think about which modules can be instantiated (perhaps Group,
>> StudyUnit, ResourcePackage, etc.) Note that if we make such a policy, it
>> will not be enforced by the parser, only by the documentation.
>>
>> Anyway, let me know what you think, and I will try to formulate a plan for
>> cleaning these up.
>>
>> Cheers,
>>
>> Arofan
>>
>> _______________________________
>>
>> Schema Imports for DDI 3.0 CR2a
>> _______________________________
>>
>>
>> archive.xsd
>>
>> - reusable.xsd
>> - organization.xsd (pre-CR3)
>>
>> comparative.xsd
>>
>> - conceptalcomponent.xsd
>> - datacollection.xsd
>> - logicalproduct.xsd
>> - reusable.xsd
>>
>> conceptualcomponent.xsd
>>
>> - reuseable.xsd
>>
>> datacollection.xsd
>>
>> - xml.xsd
>> - reuseable.xsd
>>
>> dataset.xsd
>>
>> - reuseable.xsd
>> - physicaldataproduct.xsd
>>
>> dcelements.xsd
>>
>> - simpledc20021212.xsd
>>
>> ddiprofile.xsd
>>
>> - reuseable.xsd
>>
>> ddi-xhtml11.xsd
>>
>> - xml.xsd (everything else is with includes)
>>
>> ddi-xhtml11-model-1.xsd
>>
>> [None]
>>
>> ddi-xhtml11-modules-1.xsd
>>
>> [None]
>>
>> group.xsd
>>
>> - reusable.xsd
>> - archive.xsd
>> - comparative.xsd
>> - conceptualcomponent.xsd
>> - datacollection.xsd
>> - logicalproduct.xsd
>> - physicaldataproduct.xsd
>> - physicalinstance.xsd
>> - ncube_recordlayout.xsd
>> - tabular_ncube_recordlayout.xsd
>> - inline_ncube_recordlayout.xsd
>> - studyunit.xsd
>> - organization.xsd (Pre-CR3)
>> - ddiprofile.xsd
>>
>> inline_ncube_recordlayout.xsd
>>
>> - xml.xsd
>> - reuseable.xsd
>> - physicaldataproduct.xsd
>>
>> instance.xsd
>>
>> - xml.xsd
>> - reuseable.xsd
>> - archive.xsd
>> - dcelements.xsd
>> - group.xsd
>> - studyunit.xsd
>>
>> logicalproduct.xsd
>>
>> - reuseable.xsd
>>
>> ncube_recordlayout.xsd
>>
>> - xml.xsd
>> - reuseable.xsd
>> - physicaldataproduct.xsd
>>
>> organization.xsd (Pre-CR3 - moves into archive.xsd in CR3)
>>
>> - reuseable.xsd
>>
>> physicaldataproduct.xsd
>>
>> - xml.xsd
>> - resuable.xsd
>>
>> physicalinstance.xsd
>>
>> - reuseable.xsd
>>
>> reuseable.xsd
>>
>> - xml.xsd
>> - ddi-xhtml11.xsd
>> - dcelements.xsd
>>
>> simpledc20021212.xsd
>>
>> - xml.xsd
>>
>> studyunit.xsd
>>
>> - reusable.xsd
>> - archive.xsd
>> - conceptualcomponent.xsd
>> - datacollection.xsd
>> - logicalproduct.xsd
>> - physicaldataproduct.xsd
>> - physicalinstance.xsd
>> - ncube_recordlayout.xsd
>> - tabular_ncube_recordlayout.xsd
>> - inline_ncube_recordlayout.xsd
>> - ddiprofile.xsd
>>
>> tabular_ncube_recordlayout.xsd
>>
>> - xml.xsd
>> - reuseable.xsd
>> - physicaldataproduct.xsd
>>
>> xml.xsd
>>
>> [None]
>>
>>
>> _______________________________________________
>> DDI-SRG mailing list
>> DDI-SRG at icpsr.umich.edu
>> http://www.icpsr.umich.edu/mailman/listinfo/ddi-srg
>>
> 
> Wendy L. Thomas                          Phone: +1 612.624.4389
> Data Access Core Director		 Fax:   +1 612.626.8375
> Minnesota Population Center              Email: wlt at pop.umn.edu
> University of Minnesota
> 50 Willey Hall
> 225 19th Avenue South
> Minneapolis, MN 55455
> _______________________________________________
> DDI-SRG mailing list
> DDI-SRG at icpsr.umich.edu
> http://www.icpsr.umich.edu/mailman/listinfo/ddi-srg