unitDictionay additions made should we do a supplemental release?

[Dan Higgins]

Hi All,
    I agree with Tim's comments. I vote No on the two week release 
although I think we should discuss the whole unit problem in some 
detail. I think the current unitDictionary is probably missing hundreds 
of units that somebody might want to use sometime. Changing is everytime 
someone comes up with a new unit just doesn't seem like a good idea.
    I have been writing some XSL transforms to search the unitDictionary 
and replace abbreviations with the full unit id, so I think it could be 
removed from the attribute schemas and checked in the eml-parser. But we 
also have the oprion of using 'customUnit' for any units not in the 
unitDictionary.

Dan Higgins

----

Tim Bergsma wrote:

>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
>>    
>>
>
>  
>