unitDictionay additions made should we do a supplemental rele ase?
Peter McCartney
peter.mccartney at asu.edu
Tue Feb 11 12:32:42 PST 2003
I agree to points 1 and 2 - I think the process david proposed could ensure
both of these. for point 3, we could provide a web service to return
documents by version#. We could then provide a simple jsp interface to this
for manual downloads by version#, while at the same time letting software
developers build a "live update" function against this service if they
wished. Id have to attempt, or look at, some solutions to answer #4 - but in
general, im not opposed to giving up the enumerations being declared in the
schema as opposed to having to write tools to get them from the supporting
files. It only means that xerces alone wont detect an entry error, but im
finding that it takes custom programming to render xerces output into
meaningful information anyway.....
Peter McCartney (peter.mccartney at asu.edu)
Center for Environmental-Studies
Arizona State University
-----Original Message-----
From: Matt Jones [mailto:jones at nceas.ucsb.edu]
Sent: Tuesday, February 11, 2003 12:56 PM
To: Peter McCartney
Cc: 'Eml-Dev'
Subject: Re: unitDictionay additions made should we do a supplemental rele
ase?
I think that being able to update unit definitions independently from
the EML spec is a good idea. I think we can do this and maintain
complete backward compatibility (e.g., all eml 2.0.0 documents would be
valid under 2.1.0, so no changes required for people using 2.0.0). A
couple of issues come to mind:
1) We need to be able to version the unit releases, so that people
can know if a listed standardUnit is simply missing, or if they are
using an older version of the published standard units for validation.
For example, if we release a new version of the unitDictionary (version
8) that includes a new unit "foo", an older processor that only knows
about unitDictionary version 7 will fail to recognize the unit. It
would be nice to be able to write processors that can recognize that
they are missing the unitDictionary that would be needed to define a
given standardUnit so that they can go get the newer unitDictionary
rather than just failing. Maybe a "version" attribute to the
"standardUnit" element would be in order, and some mechanism of labeling
the unitDictionary with its version?
2) We need to be careful about changing units that have been
released, or else we end up pulling the rug out from under people wrt
unit semantics. It would be crazy if a bunch of people referenced the
unit "bar" with dimension "length", and later we changed the dimension
of "bar" to "mass".
3) How do we distribute these? Should we have a standard place
where unitDictionary releases can be found?
4) If we remove the unitDictionary enumeration from eml-attribute,
we will need to shift the validation logic that checks that standardUnit
is defined to a custom check in the EML Parser. This shouldn't be a
problem, but how we do the validation will depend on how we answer my
first and third points.
Sounds like a good change to me. I also would approve the review
process that David proposed. Even though the units David added to the
dictionary are needed, I don't think we should do a patch release of EML
until after we work all of this out to our mutual satisfaction.
Matt
Peter McCartney wrote:
> Theres a side issue here, in that numbers of anything per any unit is,
> as I understand the developers of STMML, not a dimemsion. Ive been a bit
> vague on where we left things like counts and proportions.
>
> But to the main question which seesm to be, should we make updates to
> dictionary files independent of the schema versioning, I say we should
> be able to. The fact that we can't is due only to limitations on how
> enumerations for attribute and for spatial reference were declared in
> the schema. I have dealt with this in other projects using MS access
> where we isolated all enumerations in separate databases that were
> shipped and updated independently, similar to how virus definitions are
> updated independently from the software. To do this would require a 2.x
> release of eml to change the way the simpletype enumerations are
> declared so that they could be updated without requiring further changes
> to the eml-attribute and eml-spatial ref schemas.
>
> If we're voting, I vote yes on the procedure... I think that's a fine
> review process
>
> Im not going to vote on the second question because its not well
> thought
> out enough yet to vote on. I think its clear enough for someone to put
> together a draft solution that accomplishes what is described and that
> it be a targeted for a 2.x release upon which we vote. I also think that
> before releasing this, we should consider its applicability to other
> enumerations that are not finite.
>
>
> Peter McCartney (peter.mccartney at asu.edu)
> Center for Environmental-Studies
> Arizona State University
>
>
>
> -----Original Message-----
> From: Tim Bergsma [mailto:tbergsma at kbs.msu.edu]
> Sent: Tuesday, February 11, 2003 8:47 AM
> To: David Blankman
> Cc: Eml-Dev (E-mail)
> Subject: Re: unitDictionay additions made should we do a supplemental
> release?
>
>
> David,
>
> Is this a call for a vote, or are the voting questions "proposed"
> voting
> questions? If this is a call for a vote, I vote No on the two week
> release, because I want to know the answers to the discussion questions
> before I agree, and because two weeks does not sound long in development
> time. I vote yes on the proposed procedure.
>
> Tim.
>
> > David Blankman wrote:
> >
> > Prior to the release of eml 2.0.0 we discussed adding
> numberPerLiter > and numberPerMillilter to the unitDictionary.
> Somehow this was not > done. I sent an email to the LTER information
> managers requesting that > they review the unitDictionary to see if
> there are any other units > that ought to be in the dictionary. >
> > I have added these two units to the unitDictionary in cvs.
> >
> > In previous discussions, we agreed on a policy that the unitDictionary
> > could be updated independently of a full eml maintenance release.
> > While we had talked about the idea in principle, Matt reminded me that
> > it is not that simple, because currently the unitDictionary items are
> > embedded in eml-attribute.xsd as enumerations. This means that
> > additions to the unitDictionary.xml without a modification of
> > eml-attribute.xsd is relatively meaningless.
> >
> > Adding units to the unitDictionary has two parts, one easy, one more
> > challenging.
> >
> > First, the easy one--what is the procedure/policy for adding units?
> >
> > Proposed procedure:
> > 1. Someone from the ecoinformatics community sees the need for a new
> > unit. 2. That person enters a bugzilla bug.
> > 3. Someone from eml-dev enters the new unit and updates
> > unitDictionary.xml in cvs.
> > 4. That person requests a vote from the eml-dev group on the inclusion
> > of the new unit.
> >
> > Second, the thornier issue. What is the mechanism for distributing the
> > change? Matt brought up the idea of decoupling the unitDictionary from
> > EML, that is, removing the enumerations from eml-access.xsd. To do
> > this would require a new process for validating the units. One
> > possibility is adding a feature to the emlParser application to check
> > the unitDictionary.xml file.
> >
> > Questions for discussion:
> > 1. Should we decouple the unitDictionary from EML so that additions to
> > the unitDictionary would not require an EML release? 2. If you agree
> > that unitDictionary should be decoupled what mechanism should be
> > developed to validate units?
> >
> > Voting Question:
> > 1. After a two week period (time to allow for a review of
> > unitDictionary) distribute a maintenance release of eml to reflect the
> > addition of numberPerLiter and numberPerMillilter?
> >
> > If you vote NO, please state your rational.
> >
> > 2. I agree with the Proposed Procedure/Policy for making additions to
> > the unitDictionary. If you vote NO, please state your rational.
> >
> > --
> > David E. Blankman
> > Database Integration Developer
> > Long Term Ecological Research Network Office
> > University of New Mexico
> > 801 University, SE #104
> > Albuquerque, NM 87106
> > (505) 272-7346 / (505) 272-7080 FAX
>
> --
> Tim Bergsma
> LTER Information Manager
> W.K. Kellogg Biological Station
> Michigan State University
> Hickory Corners, MI 49060
> 629/671-2337
> tbergsma at kbs.msu.edu
> http://lter.kbs.msu.edu _______________________________________________
> eml-dev mailing list
> eml-dev at ecoinformatics.org
> http://www.ecoinformatics.org/mailman/listinfo/eml-dev
>
--
*******************************************************************
Matt Jones jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/ Fax: 425-920-2439 Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
Interested in ecological informatics? http://www.ecoinformatics.org
*******************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030211/3e2010e4/attachment.htm
More information about the Eml-dev
mailing list