[eml-dev] EML 2.1.0 update, part II

Thu Sep 25 09:57:51 PDT 2008

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>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=
> 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
> 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
> http://sbc.lternet.edu
> ========================
>
>
>
> ---------- Forwarded message ----------
> From: "Margaret O'Brien" <mob at icess.ucsb.edu>
> To: eml-dev <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
> http://sbc.lternet.edu
> ========================
>
> _______________________________________________
> Eml-dev mailing list
> Eml-dev at ecoinformatics.org
> http://mercury.nceas.ucsb.edu/ecoinformatics/mailman/listinfo/eml-dev
>
> _______________________________________________
> Eml-dev mailing list
> 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                       Ph: 1-907-523-1960
http://www.nceas.ucsb.edu/ecoinfo
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20080925/374bb148/attachment.html>