[eml-dev] EML 2.1.0 update, part II
Margaret O'Brien
mob at icess.ucsb.edu
Thu Sep 25 10:58:18 PDT 2008
Marratech would be great to get all the eml-devs together, and using
this date and time means we can use the regular wednesday slot for
coordination between morpho and metacat.
margaret
Matt Jones wrote:
> Hi Margaret,
>
> Thanks for your incredibly hard work on this EML release and for your
> great summaries. They are so useful.
>
> I think the issues you raise require some discussion before we decide
> what to do on each. Part of it is we should decide how quickly we want
> to get this release out, as adding more changes requires time and
> testing. Also, there are some subtle issues that should be discussed
> for several of those bugs. I suggest that we have a Marratech
> conference call next week if you and others are available. I'll
> propose a candidate time:
>
> Tuesday, Sept 30 at 9am pacific time
>
> Does this work for most interested people? If not, what times would
> you be available next week?
>
> Matt
>
> On Mon, Sep 22, 2008 at 11:38 AM, Margaret O'Brien <mob at icess.ucsb.edu
> <mailto:mob at icess.ucsb.edu>> wrote:
>
> Hi all -
> To reiterate the first part of this update (attached), since the
> EML2.1.0 schema is now backward-incompatible, we have opened the
> door for other enhancements to be included. So we can consider
> other new features which might make it a better (and more useful)
> step forward.
>
> There are 10 schema changes listed here which have, to varying
> degrees, impeded current uses. They fall into four general groups,
> where the problem could be mitigated by a change to a)
> cardinality, or b) data typing, c) feature requests, or d)
> housekeeping (e.g. naming inconsistencies). They are presented
> roughly in order of the effort required to make the change, but
> they require varying degrees of discussion among eml-dev and other
> interested parties. These 10 have been retargeted in bugzilla for
> 2.1.0 to make them stand out.
>
> Please review and comment on these issues, either here or in the
> individual bug entries.
>
>
> Cardinality:
> 1. EML should be able to handle "ongoing" data sources
> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1794
> This bug highlights data products which cannot have an end date
> accurately assigned to them. Particularly as Barbara describes,
> that EML needs to be capable of describing more than just static
> datasets. The simplest fix it to make the endDate tag optional.
> This does not free authors from the responsibility of including
> end dates for datasets that are static snapshots, but are planned
> to be appended in the future.
> discussion thread:
> http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/2004-October/001032.html
>
> 2. Unable to describe SOM map projections
> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2125
> This problem could be easily addressed by relaxing the cardinality
> on some elements, as long as that doesn't open the door for abuses
> when describing other projections. Is this the best solution? or
> necessary now? This needs input from someone better versed in
> spatial data than I am.
>
>
> Naming inconsistencies:
> 3. bug 1152 dateTime vs datetime
> 4. bug 2568 methods vs method
> these are mostly housekeeping, but require concommitant changes to
> the eml display stylesheets, and also to be included in a
> 201-to210 conversion stylesheet. So they fall second in term of
> effort required.
>
>
> Typing:
> 5. dataTable/.../attribute bounds group, retype xs:decimal to float
> See the recent comments in bugzilla:
> http://bugzilla.ecoinformatics.org/show_bug.cgi?id=2272
> Other data types may warrant reconsideration, particularly lats
> and longs which are xs:float, but should probably be decimal
>
> 6. xs:string - TextType, for some fields
> Everyone seems to agree that <title> is for presentation, but
> should others be considered? Chris was going to produce a list of
> candidates.
>
>
> Feature requests
> These two elements are all fairly straightforward to add, if the
> dev group agrees they are warranted.
> 7. http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3164 add a
> contact tree to literature.xsd
> 8. http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3165
> description of a url, which could transformed into the anchor tag
> content
>
> These last two items are related to each other, and more
> complicated to implement. Accommodating them may require that
> geographicCoverage be restructured.
> 9. http://bugzilla.ecoinformatics.org/show_bug.cgi?id=3488 datum
> added to geographicCoverageType
> 10. http://bugzilla.ecoinformatics.org/show_bug.cgi?id=1019
> altitude units recieve an enumeration list (lengths)
>
>
> OTHER BUGS: See the list of "general bugs" at:
> http://bugzilla.ecoinformatics.org/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&component=eml%20-%20general%20bugs&email1=&email2=&emailtype1=substring&emailtype2=substring&field-1-0-0=bug_status&field-1-1-0=component&field-1-2-0=product&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&product=EML&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type-1-2-0=anyexact&type0-0-0=noop&value-1-0-0=NEW%2CASSIGNED%2CREOPENED&value-1-1-0=eml%20-%20general%20bugs&value-1-2-0=EML&value0-0-0=&votes=&order=bugs.target_milestone%2Cbugs.bug_id&query_based_on=
> <http://bugzilla.ecoinformatics.org/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&component=eml%20-%20general%20bugs&email1=&email2=&emailtype1=substring&emailtype2=substring&field-1-0-0=bug_status&field-1-1-0=component&field-1-2-0=product&field0-0-0=noop&keywords=&keywords_type=allwords&long_desc=&long_desc_type=allwordssubstr&product=EML&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type-1-2-0=anyexact&type0-0-0=noop&value-1-0-0=NEW%2CASSIGNED%2CREOPENED&value-1-1-0=eml%20-%20general%20bugs&value-1-2-0=EML&value0-0-0=&votes=&order=bugs.target_milestone%2Cbugs.bug_id&query_based_on=>
> and look for targeted beyond 2.1.0, postponed or unspecified.
>
>
> Regards,
> Margaret
>
> --
>
>
> ========================
> Margaret O'Brien
> Information Management
> Santa Barbara Coastal LTER Marine Science Institute
> University of California
> Santa Barbara, CA 93106-6150
>
> 805-893-2071
> mob at icess.ucsb.edu <mailto:mob at icess.ucsb.edu>
> http://sbc.lternet.edu
> ========================
>
>
> --
> ========================
> Margaret O'Brien
> Information Management
> Santa Barbara Coastal LTER
> Marine Science Institute
> University of California
> Santa Barbara, CA 93106-6150
>
> 805-893-2071
> mob at icess.ucsb.edu <mailto:mob at icess.ucsb.edu>
> http://sbc.lternet.edu
> ========================
>
>
>
> ---------- Forwarded message ----------
> From: "Margaret O'Brien" <mob at icess.ucsb.edu
> <mailto:mob at icess.ucsb.edu>>
> To: eml-dev <eml-dev at ecoinformatics.org
> <mailto:eml-dev at ecoinformatics.org>>
> Date: Fri, 19 Sep 2008 13:09:47 -0700
> Subject: [eml-dev] EML 2.1.0 update
> Hi eml-dev -
> Lovely to see all the chatter here. Even before today, I was
> drafting an update of 2.1.0, including some issues for discussion.
> We havent talked about what's going into EML2.1 in a while
> (although the release is slated for asap), and some people aren't
> quite sure what is there already. I hope it's pretty clear that is
> is more than the simple schema bug fixes that were originally
> planned. And since EML2.1.0 is backward-incompatible, we have
> opened the door for other enhancements.
>
> To my mind, EML 2.1.0 should be reasonably close to 2.0.1 so that
> documents are easy to upgrade, but have enough new features that
> people will be excited about using it and won't just wait around
> for the next version. Right now, 2.1 is very close to 2.0.1, but
> there are several requests out there that we could consider. Some
> of these have had comments added to bugzilla in the past few days.
>
> So this email is the summary of what is in 2.1.0 so far (straight
> out of the README in head). The next will summarize the bugzilla
> entries that haven't been addressed, some of which might be
> considered reasonable and would make 2.1 a better step forward
> without severely impacting release.
>
> These are the EML2.1.0 features that are included so far, and are
> in the head. The bug number is there if you want more information,
> and the [effect on instance docs is in square brackets] :
> 1132: eml.xsd, physical.xsd; access rule ambiguities -- NOT in
> head yet, later today or monday. [access trees moved]
> 1154: resource.xsd; required element offline has no required
> children [offline/mediumName is now required]
> 2054: eml.xsd; added the <metadata> tag to additionalMetadata [
> new required tag ]
> 3051: attribute.xsd; missing units added to enumeration list to
> match eml-unitDitionary [authors have 2 new std units]
> 3163: literature.xsd, cardinality of volume and pageRange is now
> 0..1 [authors can leave off these elements if necessary]
> 3227: coverage.xsd; gRing is declared as GRingPointType, but
> should be GRingType [authors can now use these elements]
>
> These items are behind-the-scenes (also in the head). While they
> are generally invisible to instance authors, they are certainly
> not trivial:
> 3232: EML parser limitations, parser should use
> full-schema-checking for 2.1, lax checking for 2.0
> 3480: resource.xsd, physical.xsd; refactor complexTypes:
> DistributionType and PhysicalDistributionType
> 2703: text.xsd; refined element declarations in txt:TextType for
> para, section; added ulink, citetitle
> 2083: stmml.xsd; dimension 'current' was wrongly entered as 'charge'
> 3445: stmml.xsd; non-deterministic
>
> thanks -
> Margaret
>
> --
>
>
> ========================
> Margaret O'Brien
> Information Management
> Santa Barbara Coastal LTER Marine Science Institute
> University of California
> Santa Barbara, CA 93106-6150
>
> 805-893-2071
> mob at icess.ucsb.edu <mailto:mob at icess.ucsb.edu>
> http://sbc.lternet.edu
> ========================
>
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org>
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org <mailto:Eml-dev at ecoinformatics.org>
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>
>
>
>
> --
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Matthew B. Jones
> Director of Informatics Research and Development
> National Center for Ecological Analysis and Synthesis (NCEAS)
> UC Santa Barbara
> jones at nceas.ucsb.edu <mailto:jones at nceas.ucsb.edu>
> Ph: 1-907-523-1960
> http://www.nceas.ucsb.edu/ecoinfo
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
========================
Margaret O'Brien
Information Management
Santa Barbara Coastal LTER
Marine Science Institute
University of California
Santa Barbara, CA 93106-6150
805-893-2071
mob at icess.ucsb.edu
http://sbc.lternet.edu
========================
More information about the Eml-dev
mailing list