Hi Bert,
My idea had always been to merge UGRID into CF since that would
stimulate the general uptake by other communities and limits the
chances on divergence or conflicts (same group maintaining the standard).
I'm not sure that separate versioning needs to mean separate
governance. It might just be implemented as recognition of different
rates of maturity or change. The biggest strength of using UGRID and
GridSpec from our team's perspective is governance via CF and not a
smaller group. I'd be hoping these conventions would stay under the CF
umbrella in any case.
Also, as Steve noted, even if versioning is separate now, it could be be
linked with the main CF versioning later. To me, it makes sense to wait
to do that until GridSpec and UGRID are aligned, and maybe even discrete
geometries. For a library like ours that spans the concepts and
transforms data between fields based on them, those conventions should
relate to each other where they can.
The description/version path might look like the following (specific
version numbers are arbitrary):
- now: UGRID CF candidate convention, version UGRID 0.1
- after acceptance: UGRID CF convention, version UGRID 1.0
- if UGRID were versioned with CF: UGRID CF convention, version CF 1.8.
However, cross referenced standards would be possible as well. I agree
that one will need to have static versioned copies of the conventions.
Our wiki system includes a page copy feature which can be used to
preserve documentation for older versions of the standard (although
those pages would remain editable for some). It is also possible to
export snapshots of pages to pdf and thereby really freeze that
version. Hence, I don't see technical issues for UGRID.
These static copy features, with a preference for the pdf approach,
sound perfect. That would suit our needs very well, especially if your
wiki site or some CF-managed site had version navigation. (Please
forgive the obvious/overspecification.)
How do you feel about getting a version on UGRID soonish?
Best,
- Cecelia
Best regards,
Bert
-------
On 06/12/2012 01:16, Cecelia DeLuca wrote:
Steve, I agree that solutions may be different in the near term and
long term,
that seems reasonable - and Alex, I understand about coordinating
with Jeff.
I still worry about maintaining versions on a wiki ... I think to work in
practice it would need to be set up with some attention to navigation.
Some more background...
ESMF is already building versioned software based on UGRID and (sort of,
in a single tile way) GridSpec. We need to cite distinct
and static versions of the conventions for both developers and users,
since
our software may not work, or our documentation may be wrong, if the
conventions evolve. Further, since we're committed to supporting ESMF
versions for up to three years, we expect, at any given time, to have
access
to multiple static versions of these conventions.
For the last couple ESMF releases, we used the URL of the UGRID wiki with
an associated date as the version reference, but that's not the
greatest solution.
Hence the request for static versioned documents, but I know they are
a pain
to produce. At a minimum, if GridSpec and UGRID stay on wikis, it
would be
helpful to have a version table with links on the front wiki page so
that someone
who ended up there could quickly see and navigate to other versions.
Does
that make sense?
Thanks,
- Cecelia
On 12/5/2012 2:17 PM, Steve Hankin wrote:
Cecelia et. al.,
An important and somewhat awkward topic. I like your suggestion,
myself. I might suggest slightly different terminology to describe
it, though. I think we are proposing that _for the present_
*gridspec *and/or *ugrid *(there need not be the same answer for
both) ought to be published as independent standards, and therefore
have their own version numbering. These standards publications
would internally refer to CF as a "normative standard"
(https://en.wikipedia.org/wiki/Normative#Standards_documents --
"considered to be a prescriptive part")
* They could be published on their own Wiki sites, or they could
alternatively be published on the CF site. The latter approach
would emphasize their close relationship to CF -- part of a
family of standards. But they would not be "chapters" in the CF
document ... at this time.
* The CF document would point to them, say, in brief appendices
that explained that gridspec and/or ugrid were at this time
being managed as separate standards.
* There would preferably be a generally agreed strategy, that when
judged sufficiently stable at a future time, the ugrid and
gridspec standards would become chapters in some future version
CF ... but not yet.
Underlying any final decision would be an open-eyed awareness of how
stable and well-tested ugrid and/or gridspec rightly are (or are
not) at the current time. This would need to be judged by people
who use the standards on a day to day basis *_and_* interchange
files containing outputs of distinct models with one another. I do
not myself have this level of day-to-day familiarity to judge the
demonstrated stability and interoperability of either gridspec or
ugrid datasets ... but it seems like you and your group probably do,
Cecelia, which is why I'm inclined to back this as a sensibly
cautious idea that leaves the wiggle room needed for rapid evolution.
- Steve
==========================
On 12/5/2012 11:43 AM, Cecelia DeLuca wrote:
Thanks Alex and Jeff - sorry, I'm not clear on how you plan to
proceed.
Is the following an acceptable plan?
Create a separate version now for GridSpec, so that it is not
versioned in lockstep
with the rest of CF.
Create a fixed (non-wiki) specification document for this version
of GridSpec.
[Again, that would be nice because then we could begin to build
software on it now.]
When changes or updates occur, update the version and create a new
specification
document.
Point to the GridSpec version and spec document that is current
when CF 1.7 comes out.
If this isn't an okay plan, could you please indicate what you will
do to be sure
that GridSpec versions are unambiguous, and all versions of
GridSpec will be very
easy to retrieve?
Thanks,
Cecelia
On 12/5/2012 11:33 AM, Alexander Pletzer wrote:
Thanks Jeff!
--Alex
On 12/05/2012 11:04 AM, Jeffrey F. Painter wrote:
Yes, Gridspec didn't make it into CF 1.6 and will be in 1.7.
There's no scheduled release date, but I hope to get to it soon.
I'm sorry I couldn't reply sooner - I was on vacation from
November 22 and just got back.
- Jeff Painter
On 11/26/12 10:49 AM, Allyn Treshansky wrote:
Hello Alex,
Thank you for the reply. My comments are inline.
Thanks,
Allyn
On 11/26/2012 09:45 AM, Alexander Pletzer wrote:
Hi Allyn,
On 11/23/2012 01:02 PM, Allyn Treshansky wrote:
Hello.
I am confused as to the relationship between GridSpec and the
official CF Conventions. In particular, it's not clear
whether or not GridSpec is part of the latest version (v1.6).
According to the CF Tracker
[https://cf-pcmdi.llnl.gov/trac/ticket/63], the GridSpec
proposal has been approved. However, there is no mention of it
in the latest Convention Documentation
[http://cf-pcmdi.llnl.gov/documents/cf-conventions/1.6/cf-conventions.html].
I think Gridspec did not quite make it into CF 1.6, Jeff
Painter may know whether it will be incorporated into 1.7.
Okay. Is there a scheduled release date for v1.7?
The ticket does reference a formal extension to CF
[https://ice.txcorp.com/trac/modave/wiki/CFProposalGridspec].
Presumably, this is what users should reference for GridSpec
documentation. Is that correct,
Yes.
Okay.
or is there another document we should be using? And it
remains odd that there is no link from the v1.6 documentation
to GridSpec documentation (either that techX page or another one).
Assuming that the techX page is the correct location for
GridSpec CF documentation, it is lacking any version information.
You mean CF version?
Yes. I mean which CF version does that documentation apply to.
How will future governance be handled without that? Should we
consider the page as it stands CF version 1.6?
Also, can the GridSpec convention only be expressed as a
netCDF file?
Yes it was written for netcdf. I'm assuming that anything that
can be done in netcdf can be done in XML though I'm not a XML
specialist.
Best,
--Alex
Are there other formats (such as XML) for the CF Conventions
that support GridSpec?
Many thanks for your help.
Regards,
Allyn
--
Allyn Treshansky
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder CO 80305 USA
Email:[email protected]
Phone: +1 303-497-7734
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
Allyn Treshansky
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder CO 80305 USA
Email:[email protected]
Phone: +1 303-497-7734
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
===================================================================
Cecelia DeLuca
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder 80305-337
Email:[email protected]
Phone: 303-497-3604
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
--
===================================================================
Cecelia DeLuca
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder 80305-337
Email:[email protected]
Phone: 303-497-3604
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
DISCLAIMER: This message is intended exclusively for the addressee(s) and may
contain confidential and privileged information. If you are not the intended
recipient please notify the sender immediately and destroy this message.
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The
Netherlands, Commercial Registration Number 41146461, is not liable in any way
whatsoever for consequences and/or damages resulting from the improper,
incomplete and untimely dispatch, receipt and/or content of this e-mail.
--
===================================================================
Cecelia DeLuca
NESII/CIRES/NOAA Earth System Research Laboratory
325 Broadway, Boulder 80305-337
Email: [email protected]
Phone: 303-497-3604
_______________________________________________
CF-metadata mailing list
[email protected]
http://mailman.cgd.ucar.edu/mailman/listinfo/cf-metadata
