eml packaging

Peter McCartney peter.mccartney at asu.edu
Thu May 30 16:56:34 PDT 2002 

Another day has rushed by me here. So where are we on this? - i talked with
corinna and robin about it and they both thought there was an inherent logic
in the reference/content choice as a consistent structure for containers.

I dont mind the Container suffix in the complex type as long as it doesnt
find its way into the actual element names that people see. By using
"content" for the element containing the content, we do neatly avoid the
awkwardness cause by having two elements with the same name nested. 

On a separate note, ive been thinking about the structure Chad posted for
attributes. as i understand it, we would use this by creating a local
element (lets say "attribute"). there seem to be three complex types i could
set this to:  AttributeContainer, AttributeListType and AttributeType

Assuming that im only allowed to import the AttributeContainer complex type

<attribute>
	<attribute id="2">
		<attributeName/>
		....
	</attribute> 
</attribute>

or

<attribute >
	<attributeList id=1>
		<attribute id="2">
			<attributeName/>
			.....
		</attribute> 
		<attribute id="3">
			<attributeName/>
			.....
		</attribute> 	
	</attributeList>
</attribute>


Im not sure we need a container to provide the choice between lists versus
single attribute. we can accomplish the same thing by simly having one
complex type for a single attribute  and another one for the list that
extends the first. Frankly im beginning to see my way clear to always using
the list model for importing attributes as this tends to make the documents
more readable and would avoid us having to first figure out whether we're
being handed a list or a single. I would be even happier if we agreed that
attributeList cannot repeat. We still need the ability to assign id's and
refs to individual attributes so that we can build new attribute lists that
consist of references to existing attributes. because the attribute lists
themselves get id's you can still reference the entire attributeList if you
want to. so i would drop the complex type you have as attributeContainer and
just use what you call AttributeListType as the container for the module. If
i were really really purist, i would say that attribute belongs in one
module and attribute list should import it. we would then only import
attributeList into the other files, thereby forcing all references to
attributes to be in lists when we want them to. If we do want them to be
single, we could import only the attribute schema and allow only a single
attribute.

Peter McCartney (peter.mccartney at asu.edu)
Center for Environmental Studies
Arizona State University
480-965-6791 

-----Original Message-----
From: Dan Higgins [mailto:higgins at nceas.ucsb.edu]
Sent: Thursday, May 30, 2002 9:03 AM
To: Chad Berkley; eml-dev at ecoinformatics.org
Subject: Re: eml packaging


I like the idea also. I think the 'content'/'reference' choice makes a 
lot of sense.

Dan

Chad Berkley wrote:

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

-- 
---------------------------------
Dan Higgins
Software Developer
National Center for Ecological Analysis and Synthesis (NCEAS) 
735 State St. Rm 205 
Santa Barbara, CA 93101 
805-892-2531 
higgins at nceas.ucsb.edu 
---------------------------------



_______________________________________________
eml-dev mailing list
eml-dev at ecoinformatics.org
http://www.ecoinformatics.org/mailman/listinfo/eml-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20020530/b5726a3b/attachment.htm

More information about the Eml-dev mailing list