[VOTE] restructure date-time value descriptions

[Peter McCartney]

i dont think there much left to say about the ordinal/interval points but id
like to respond on the issue of formatString below:

before i do that, id like to clarify that for durations measured in any
single "unit" of time (years bc, julian days since year beginning, elapsed
time, etc, that we are using ratio and units, rather than datetime?

how do we handle data files where someone parsed the different units into
separate fields? (eg month, day, year, etc.)

> 
> We're attempting to model the date-time data here, aren't we?  Not the
> internal representation.  If SQL server uses:
> 
> 4:10 pm on jan 1 1980
> 
> to mean:
> 
> 16:10
> 
> That's not EML's concern, is it?  BTW, I doubt if SQL server uses that
> internally anyway, that looks like yet another datetime string

My point is that describing the string representation of a date field is
meaningless untill i write that data out into an ascii stream. If im giving
you a binary file, or a pointer to a data service, I have no control over
what string representation your software will used to render that internal
value as a string. It meaningless, so it should be made optional.
> 
> As currently modelled the formatString implies the 'precision'.
> 
> YYYY
> YYYYMM
> YYYYMMDD
> YYYYMMDDThh
> YYYYMMDDThhmm
> YYYYMMDDThhmmss

the docs do not make this 'precision' function clear. I see your point, but
i think its confounded with format. with an sql database field, i might be
able to use this content model to tell you that my datetime domain is
hours+minutes, but i can't tell you whether is HH:MM or HH-MM, etc.
likewise, i could say its year+month+date but i cant say dd/mm/yy versus
YYYYDDMM - i have no control over that.

so to modify your example below, i might suggest:

	<dateTimeDomain>
		<contentScope>YMD</contentScope>
		<formatString>DD-MM-YYYY<formatString> *this would be
optional
		etc.....
> etc. or:
> 
> ss.s
> ss.ss
> ss.sss
> 
> For the domain of a time field wouldn't something like this work?
> 
>          <measurementScale>
>            <ordinal>
>              <dateTimeDomain id="dd.2">
>                <formatString>HHSS</formatString>
>                <minimum>0000</minimum>
>                <maximum>2359</maximum>               
>              </dateTimeDomain>
>            </ordinal>
>          </measurementScale>
> 
> 
> 
> Accommodating something you disagree with in the name of expediency
> certainly won't accomplish the quality in EML I'm certain you are
> looking for.  If you're convinced that date-time is interval then
> stand up and be counted.  You've got better clarity of conviction than
> I do, because it sure doesn't look that black-and-white from here.
> 
> I interpret this vote to mean that the 'ordinal' kludge has advantages
> over the 'interval' kludge, and works sufficiently so that EML 2.0 can
> see the light of day.
> 
> -Scott
> -- 
> Scott E. Chapal_________________________________________________
> Database & Network Manager             scott.chapal at jonesctr.org
> J.W. Jones Ecological Research Center          229.734.4706 x227
> Rt. 2. Box. 2324. Newton, GA 31770-9651        229.734.6650 :FAX
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20021106/c27d19bd/attachment.htm