eml packaging

[Chad Berkley]

I like the idea of putting the content in the "content" tag.  I didn't
really like the "Container" suffix.  Does anyone else have any comment
about this?  If not, I'll change all of the schemas.  I'll give you till
noon PDT to comment before I change them.

chad

On Wed, 2002-05-29 at 17:26, Peter McCartney wrote:
> The coverage file you checked in didnt quite look like what i was expecting
> so i made edits and am attaching it here (eml-coverage.xsd) . 
> 
> In doing so, i was thinking of how we could come up with a way to cut out
> some of the complexities of complex typing and to better hide some of this
> within the modules. By defining complex types for the content model and then
> for the container, we are exposing both although we really only want people
> to use the container one and not the content model one. This made me wonder
> if we really needed a complex type for the content model since it is
> actually only used within the container.  So i experiemented with just using
> a local element to define the content model and attaching the id, system,
> and scope attributes to that element. I also experimented with a better
> naming convention and came up with dropping the "Container" suffix so that
> the complex type we import is more familiar, and adding an "Info" suffix to
> the element that contains the content model (see eml-coveragesimple.xsd and
> eml-protocolsimple.xsd).  Assuming we name the importing element "coverage"
> our instance files would look like:
> 
> <coverage>
> 	<coverageInfo id=23 system=caplter scope=document>
> 		<geographicCoverage>
> 		.....
> 		</geographicCoverage>
> 	</coverageInfo>
> <coverage>
> 
> 
> This puts "coverage" as the main element and it will contain either
> <coverageInfo> or <references>. Then i though hmmm....who the hell cares
> what the lower element is called - we know that its only there as a dummy
> element to hold the content model so we can use the choice structure.
> Sooooo...how about if we just always call it "content"? that way there are
> always only two elements we should expect to see under the imported element
> - <content> or <references> (see eml-coveragesimple2 and
> eml-protocolsimple2). so our instance snippet would now look like this:
> 
> <coverage>
> 	<content id=phm.234 system=caplter scope=system>
> 		<geographicCoverage>
> 		.....
> 		</geographicCoverage>
> 		<temporalCoverage>
>             ......
> 		</temporalCoverage>
> 	</content>
> <coverage>
> 
> OR
> 
> <coverage>
> 	<references>
> 	phm.234
> 	</references>
> <coverage>
> 
> If you're not already too sick of all this, let me know what you think....
> 
> Peter McCartney (peter.mccartney at asu.edu)
> Center for Environmental Studies
> Arizona State University
> 480-965-6791 
> 
> -----Original Message-----
> From: Chad Berkley [mailto:berkley at nceas.ucsb.edu]
> Sent: Wednesday, May 29, 2002 3:52 PM
> To: eml-dev at ecoinformatics.org
> Subject: eml packaging
> 
> 
> Hi,
> 
> I just checked in a bunch of changes to eml.  namely, I added the
> references element and an id attribute to each module for packaging
> purposes.  I have not added inlined elements for direct nesting (i.e. an
> attribute typed tag in eml-entity).  I will probably attempt this feat
> tomorrow.  Please take a look at what I have done and send me any
> feedback that you may have.
> 
> thanks,
> chad
> -- 
> -------------------------------
> Chad Berkley
> National Center for Ecological
> Analysis and Synthesis (NCEAS)
> 735 State St. Ste. 204
> Santa Barbara, CA 93101
> 805-892-2530
> berkley at nceas.ucsb.edu
> -------------------------------
> 
> _______________________________________________
> eml-dev mailing list
> eml-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/eml-dev
> 
-- 
-------------------------------
Chad Berkley
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Ste. 204
Santa Barbara, CA 93101
805-892-2530
berkley at nceas.ucsb.edu
-------------------------------