Joe Sirott wrote:
> Hi Steve,
>
> I prefer an informal process. Perhaps we should let the discussion
> take its course and issue a new revision when everyone agrees that
> it's needed. I'm willing to write that revision, if it's OK with
> everyone else out there.
Hi Joe et. a.,
There are trade-offs to both formal and the informal approaches. I'd
like to suggest a two step process.
1. Informal at first:
Since this is the very first release of a new specification there
is likely to be a flurry of issues opening up in quick
succession. The best approach is likely to be just what you have
suggested -- following informal discussions issue a revision based
on the issues that have been discussed ... and perhaps to make a
list of ideas that were raised but not resolved. The outcome of
that in (say) a couple of months to six months -- whether it is
one revision or more -- could be regarded as the first "stable"
specification of DAPPER.
2. More formal after it stabilizes:
After years of working with and growing the CF conventions through
a very informal email process, the down side is that years later
we find the same issues re-surfacing and we have no clear track
record of why particular conclusions were drawn in the past.
Also, some ideas get careful discussion. Others slip through with
little discussion and little notice ... to be regretted later.
The CF community has concluded that a minimal level of formality
would help to minimize problems of this sort:
* make sure that the discussions are all found on a single
searchable email list. In the case of DAPPER, PCMDI could
host a "dods-dapper" email list. (Maybe this should get
started right away.)
* carefully version-control the standard document and keep the
versions under source code control so they can be
differenced on-line by anyone. PCMDI will be hosting a
Subversion server for this purpose.
* use a system like Trac to identify significant issues that
are raised, discussed and closed. PCMDI will be hosting a
Trac server for this purpose. This will require a
moderator. Yes this is a nuisance. But I think we're all
in agreement that the value of good standards to the
community justifies a significant effort.
Does this seem a reasonable compromise? Comments?
- Steve
>
> - Joe
>
> Steve Hankin wrote:
>> Hi John, Joe, _Kyle,_ et. al.,
>>
>> Sorry for the delay joining the conversation. I have been away on
>> travel.
>>
>> Yes -- when the funding was found to support Joe in drafting this
>> specification the intention was that it would be followed by open
>> community discussions of the many individual issues. The folks at
>> PCMDI who are hosting the new CF development site
>> (http://cf-pcmdi.llnl.gov/) generously agreed to host these discussions.
>>
>> Kyle -- how should we handle this? The discussion thread has already
>> taken off -- I count 9 messages so far on the dods-tech email list.
>> Would you like me to forward them to you? Joe's initial document is
>> available at
>> http://www.epic.noaa.gov/epic/software/dapper/dapperdocs/conventions/
>>
>> Presumably this discussion will require a moderator and a document
>> editor (could be the same person). Joe, are you willing to help with
>> this? Jennifer? others?
>>
>> - Steve
>>
>> =====================================================
>>
>> John Caron wrote:
>>> Hi Joe, et al:
>>>
>>> We have some various comments on this. Im wondering if you would
>>> prefer to have a seperate conversation on a possible new version of
>>> the spec, or just discuss the spec as it stands? I guess im
>>> wondering if this is the place to have the discussion Steve Hankins
>>> suggested:
>>>
>>> (Steve's original email)
>>>
>>> I'm seeking your thoughts here are on how the community can move
>>> rapidly towards the development of a written specification for the
>>> 2-level Sequence representation in OPeNDAP. (I'll refer to this
>>> below as the "DAP-2LS" conventions.) It looks like the time may be
>>> right next year for pretty rapid growth in the use of OPeNDAP for
>>> conveying in-situ data. Funding will probably be available for
>>> efforts along these lines. A written specification is needed if the
>>> community is to take full advantage of these opportunities.
>>>
>>> Between the DAPPER server and GDS there are successful example
>>> implementations to work from. Many of the details of the
>>> specification (e.g. encoding of time) can probably be borrowed from
>>> CF. The emerging PyDAP work promises to bring relational databases
>>> into the fold, too.
>>>
>>> Clearly funding may be needed to entice someone to take on this
>>> task. I believe that we can find a source of those funds in NOAA if
>>> we act quickly. Even if only an initial, draft specification were
>>> to be developed at this time -- with community comments and
>>> discussion left to follow later -- this would be an important
>>> contribution. Multiple venues for community discussion of
>>> CF-related conventions are taking form. One at Unidata (by
>>> September?) will host discussions about unstructured grid (finite
>>> element) conventions. Another at LLNL is getting started now to
>>> press forward with the CF conventions for more complex curvilinear
>>> grids. With an initial specification of DAP-2LS conventions in hand
>>> I imagine we can entice someone to host a community discussion,
>>> since access to observations is important to everyone.
>>>
>>> - steve
>>>
>>> P.S. I am just cheer-leading this effort. I do not expect be
>>> directly involved, myself. The pay-off to the community --
>>> advancing data interoperability, OPeNDAP, the Common Data Model,
>>> etc. etc. -- just seems too big to ignore. "
>>>
>>
>> --
>> --
>>
>> Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
>> 7600 Sand Point Way NE, Seattle, WA 98115-0070
>> ph. (206) 526-6080, FAX (206) 526-6744
>
--
--
Steve Hankin, NOAA/PMEL -- Steven.C.Hankin at noaa.gov
7600 Sand Point Way NE, Seattle, WA 98115-0070
ph. (206) 526-6080, FAX (206) 526-6744
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cgd.ucar.edu/pipermail/cf-metadata/attachments/20061006/a0f68aca/attachment-0002.html>
Received on Fri Oct 06 2006 - 11:38:42 BST
