<p dir="ltr">Hey Michael,</p>
<p dir="ltr">So, the main request from my design document is somehow augmenting the information in Registry with additional information that the actual Registry parser wouldn't use. The main use for this extra information is allowing Registry defined attributes that can be written into fields/streams to help with CF Compliance. The additional use is that we can parse this extra information to help generate our users guides.</p>
<p dir="ltr">But about your questions....</p>
<p dir="ltr">I am suggesting the use of either XML or JSON, mostly because they are standard pre-defined formats that are already defined. XML at least is already in use by CESM, so it seems like CESM users would not have a difficult time editing Registry (if they wanted to). </p>
<p dir="ltr">These formats also allow cores to append arbitrary information to Registry depending on what their requirements are, and allows us to specify a Schema that can be used to define the required attributes in Registry, and then verify the validity of the Registry file.</p>
<p dir="ltr">So, I think that the answers are yes to 1), but no to 2), and regardless of what we do end up having as our format we can write a parser. Though if we do use a standard format, we can make use of pre-existing parsers.</p>
<p dir="ltr">I think largely the format won't affect developers much, except when they have to edit Registry. The fortran code that gets generated should be exactly the same as it is now.</p>
<p dir="ltr">Let me know if you have any other questions or concerns.</p>
<p dir="ltr">Thanks,<br>
Doug</p>
<div class="gmail_quote">On Feb 28, 2013 5:42 PM, "Michael Duda" <<a href="mailto:duda@ucar.edu">duda@ucar.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi, Doug (and others).<br>
<br>
Just to check my understanding of the issues, are the arguments for<br>
moving to either XML or JSON that<br>
<br>
1) because these are widely supported formats, there would be tools<br>
available to automatically generate documentation from our registry<br>
files if they were to be in one of these formats; and<br>
<br>
2) if we were to employ an XML or JSON parsing library in the registry<br>
code, we could easily parse the registry file into data structures, from<br>
which we could then generate Fortran code as we do now?<br>
<br>
Are there other arguments in favor of either of these formats?<br>
<br>
Michael<br>
<br>
<br>
On Thu, Feb 28, 2013 at 03:29:27PM -0700, Doug Jacobsen wrote:<br>
> Hi again everyone,<br>
><br>
> To try and help fuel the discussion about the format of Registry, I've<br>
> decided to try and mock up two versions of Registry. There is the current<br>
> proposal in the design document for XML, but I slightly modified it in a<br>
> way that makes it more closely mirror whats currently in the code. Another<br>
> developer here recommended I look at JSON as well, so I put together an<br>
> example of the same XML Registry, but in the JSON format.<br>
><br>
> These are not complete versions of what they would look like in the end,<br>
> but I tried to give examples of at least everything I wanted to have in the<br>
> file in the end. Please take a bit and download the two files. You can open<br>
> them up in your favorite editor and look around to see if you like or<br>
> dislike either of them.<br>
><br>
> One thing to note, I'm not super familiar with JSON so some of the<br>
> formatting might be incorrect in the version I sent you. So there might be<br>
> some small errors, but I think largely it's correct.<br>
><br>
> Some small notes:<br>
> One fairly large benefit to using either of these two formats is that we<br>
> can define a JSON or XML schema and do validation checks on our Registry<br>
> file prior to using it.<br>
> One fairly large negative to the JSON format is that you can't write<br>
> comments. The only want to write comments is to define an unused key:value<br>
> pair that is your comment.<br>
><br>
> Again, any questions or comments are appreciated.<br>
><br>
> Thanks,<br>
> Doug<br>
><br>
><br>
> On Tue, Feb 26, 2013 at 10:43 AM, Doug Jacobsen<br>
> <<a href="mailto:jacobsen.douglas@gmail.com">jacobsen.douglas@gmail.com</a>>wrote:<br>
><br>
> > Hello Everyone,<br>
> ><br>
> > There are two design documents attached (and also recently committed to<br>
> > the repo). I put two in this email because on of them requires the other,<br>
> > and provides something to consider in the first.<br>
> ><br>
> > First, is the run-time I/O document that also includes auto-documentation.<br>
> > This requires some rather significant modifications to Registry, with the<br>
> > end goal being a verbose format for Registry that allows documentation of<br>
> > fields, namelists, and dimensions to be written into the Registry file. I<br>
> > have provided an XML proposal for Registry conversion in this document, but<br>
> > this could be a different format. This format will also be used to enforce<br>
> > CF compliance in our output files (writing out field level attributes and<br>
> > what-not).<br>
> ><br>
> > This document also includes description (although rough currently) of an<br>
> > auto-documentation parser script. Currently I have a script written in<br>
> > python that parses Registry and an additional documentation file (as a<br>
> > test) that generates tables and sections that will be included in our users<br>
> > guide.<br>
> ><br>
> > One of the main short term benefits of this project is that it allows ease<br>
> > of documentation. However the second benefit is the creation of a run-time<br>
> > I/O layer. This allows the creation of streams at compile time, and the<br>
> > modification of what fields are in each stream at run-time. This makes use<br>
> > of another namelist file (described in the document) to make configuration<br>
> > easy.<br>
> ><br>
> > Second, is the field statistics module design document. This provides a<br>
> > description of a generic module that can be used to compute time averages<br>
> > and field moments. Time averages and moments of fields can be specified at<br>
> > run-time, with the implementation of the run-time I/O layer.<br>
> ><br>
> > Both of these projects are rather large, and some of our documentation<br>
> > requires the first project. My hope is to begin to work on this project<br>
> > within the next few weeks so I would like to get at least the first<br>
> > document solidified sooner rather than later.<br>
> ><br>
> > So, please let me know if you have any questions of comments. Especially<br>
> > regarding the format of Registry.<br>
> ><br>
> > Thanks!<br>
> > Doug<br>
> ><br>
<br>
<br>
<br>
> _______________________________________________<br>
> mpas-developers mailing list<br>
> <a href="mailto:mpas-developers@mailman.ucar.edu">mpas-developers@mailman.ucar.edu</a><br>
> <a href="http://mailman.ucar.edu/mailman/listinfo/mpas-developers" target="_blank">http://mailman.ucar.edu/mailman/listinfo/mpas-developers</a><br>
<br>
</blockquote></div>