unitDictionay additions made should we do a supplemental release?
Scott Chapal
scott.chapal at jonesctr.org
Fri Mar 21 07:20:02 PST 2003
Has the thinking on the unit-dictionary progressed?
What is discussed below seems a bit heavyweight to me. Why can't a
versioned unit dictionary exist as a simple stand alone schema
document, referencable via a namespace declaration? Considerations for
backward compatibility would obviously apply.
Working with our climate data, I found the need for:
kiloPascal
wattsPerMeterSquared
kiloJoulePerMeterSquared
Fuel Moisture % - percentWaterContentByWeight ??
Relative Humidity is presumably unitless?
-Scott
Peter McCartney <peter.mccartney at asu.edu> writes:
> 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
> *******************************************************************
--
\SEC
More information about the Eml-dev
mailing list