eml packaging
Chad Berkley
berkley at nceas.ucsb.edu
Fri May 31 10:52:47 PDT 2002
I made a mistake in the schema. I meant to make both attribute and
attributeList repeatable (I had actually also meant to make the choice
repeatable...too much to think about). I think you are right about the
awkwardness of having attributes and attributeLists comingling. What if
the choice was like this:
<xs:choice>
<xs:element name="attribute" type="AttributeType" minOccurs="1"
maxOccurs="unbounded"/>
<xs:element name="attributeList" type="AttributeListType"
minOccurs="1" maxOccurs="unbounded"/>
</xs:choice.
That way, one must choose either to put in one or more attributes or an
attributeList, but not both.
does anyone else besides peter and me have any comments on the structure
of this module? I think it's pretty important for parsing and using
entities and attributes.
chad
On Fri, 2002-05-31 at 10:37, Peter McCartney wrote:
> Ok. im looking at 1.36. naming the importing element "attributeSection"
> seems to avoid some of the name redundancy, but I dont see that 1.36 allows
> the instance of two attributes and one attributeList as you show at the end
> of your message (Attribute allows only one attribute or one attributeList).
> Frankly, I'm a bit worried that allowing an instance that mixes multiple
> attributes and attributeLists would be very awkward to process. I think I'm
> partial to the less flexible two-complex type model for the very reason that
> it prevents end-users from choosing either single or lists I like the idea
> of every entity having one attributeList that has an id, with all the
> attributes getting their own id's). that way our content is more
> predicatable since we can choose in the schema design when its appropriate
> to define (or reference) a single attribute (as in the example i gave for
> defining an existing variable as the enumeratedDomain) or a list (as in
> eml-entity and eml-constraint).
>
>
>
> 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: Friday, May 31, 2002 8:55 AM
> To: Peter McCartney
> Cc: Eml-Dev (E-mail)
> Subject: RE: eml packaging
>
>
> See my comments inline.
>
> On Thu, 2002-05-30 at 16:56, Peter McCartney wrote:
> > 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.
> >
>
> I agree. I've removed the Container suffixes and added the "content"
> element for every module.
>
> > 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
> >
>
> The way it is now, there is only a choice between an attribute and
> attributeList in the complexType "Attribute"
> <xs:complexType name="Attribute">
> <xs:choice>
> <xs:element name="attribute" type="AttributeType"/>
> <xs:element name="attributeList" type="AttributeListType"/>
> </xs:choice>
> </xs:complexType>
>
> The references choice is nested farther down in the actual AttributeType
> and AttributeListType. I thought this was a logical way to keep this
> model simple. The other way to do it would be to have two complex
> types. one would be
> <xs:complexType name="Attribute">
> <xs:choice>
> <xs:element name="content" type="AttributeType"/>
> <xs:element name="references" type="xs:string"/>
> </xs:choice>
> </xs:complexType>
>
> and the other would be
>
> <xs:complexType name="AttributeList">
> <xs:choice>
> <xs:element name="content" type="AttributeListType"/>
> <xs:element name="references" type="xs:string"/>
> </xs:choice>
> </xs:complexType>
>
> I thought that was too cumbersome and didn't provide and inherent choice
> between an attribute and a list of attributes with one import.
>
> Note that the ids are nested inside of attribute and attributeList so
> each can be refenced.
>
> this allows documents of the form:
>
> <attributeSection>
> <attribute id=1/>
> <attribute id=2/>
> <attribuetList id=3>
> <attribute id=4/>
> <attribute>
> <references>2</references>
> </attribute>
> </attributeList>
> </attributeSection>
>
> comments?
>
> > 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
> --
> -------------------------------
> 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
> -------------------------------
--
-------------------------------
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
-------------------------------
More information about the Eml-dev
mailing list