<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Thanks Doug,<br>
<br>
I agree that using a standardized language for this is a good idea
as well as doing validation with a schema. My vote would be for
JSON but that's mainly because I'm more familiar with it than XML.
I also like that JSON more clearly distinguishes between
associative arrays {} and indexed arrays [].<br>
<br>
Adrian<br>
<br>
On 2/28/13 3:29 PM, Doug Jacobsen wrote:<br>
</div>
<blockquote
cite="mid:CAEn+ZpsHK-E6AVAH_6SU920rt_eOKAkJkHky_0nyqeC25xuFCQ@mail.gmail.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<div dir="ltr">Hi again everyone,
<div><br>
</div>
<div>To try and help fuel the discussion about the format of
Registry, I've decided to try and mock up two versions of
Registry. There is the current proposal in the design document
for XML, but I slightly modified it in a way that makes it
more closely mirror whats currently in the code. Another
developer here recommended I look at JSON as well, so I put
together an example of the same XML Registry, but in the JSON
format.</div>
<div><br>
</div>
<div>These are not complete versions of what they would look
like in the end, but I tried to give examples of at least
everything I wanted to have in the file in the end. Please
take a bit and download the two files. You can open them up in
your favorite editor and look around to see if you like or
dislike either of them. </div>
<div><br>
</div>
<div>One thing to note, I'm not super familiar with JSON so some
of the formatting might be incorrect in the version I sent
you. So there might be some small errors, but I think largely
it's correct.</div>
<div><br>
</div>
<div style="">Some small notes:</div>
<div style="">One fairly large benefit to using either of these
two formats is that we can define a JSON or XML schema and do
validation checks on our Registry file prior to using it.</div>
<div style="">One fairly large negative to the JSON format is
that you can't write comments. The only want to write comments
is to define an unused key:value pair that is your comment.</div>
<div><br>
</div>
<div>Again, any questions or comments are appreciated.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>Doug</div>
</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Tue, Feb 26, 2013 at 10:43 AM, Doug
Jacobsen <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:jacobsen.douglas@gmail.com" target="_blank">jacobsen.douglas@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hello Everyone,
<div><br>
</div>
<div>There are two design documents attached (and also
recently committed to the repo). I put two in this email
because on of them requires the other, and provides
something to consider in the first.</div>
<div><br>
</div>
<div>First, is the run-time I/O document that also
includes auto-documentation. This requires some rather
significant modifications to Registry, with the end goal
being a verbose format for Registry that allows
documentation of fields, namelists, and dimensions to be
written into the Registry file. I have provided an XML
proposal for Registry conversion in this document, but
this could be a different format. This format will also
be used to enforce CF compliance in our output files
(writing out field level attributes and what-not). </div>
<div><br>
</div>
<div>This document also includes description (although
rough currently) of an auto-documentation parser script.
Currently I have a script written in python that parses
Registry and an additional documentation file (as a
test) that generates tables and sections that will be
included in our users guide.</div>
<div><br>
</div>
<div>One of the main short term benefits of this project
is that it allows ease of documentation. However the
second benefit is the creation of a run-time I/O layer.
This allows the creation of streams at compile time, and
the modification of what fields are in each stream at
run-time. This makes use of another namelist file
(described in the document) to make configuration easy.</div>
<div><br>
</div>
<div>Second, is the field statistics module design
document. This provides a description of a generic
module that can be used to compute time averages and
field moments. Time averages and moments of fields can
be specified at run-time, with the implementation of the
run-time I/O layer.</div>
<div><br>
</div>
<div>Both of these projects are rather large, and some of
our documentation requires the first project. My hope is
to begin to work on this project within the next few
weeks so I would like to get at least the first document
solidified sooner rather than later.</div>
<div><br>
</div>
<div>So, please let me know if you have any questions of
comments. Especially regarding the format of Registry.</div>
<div><br>
</div>
<div>Thanks!</div>
<span class="HOEnZb"><font color="#888888">
<div>Doug</div>
</font></span></div>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
mpas-developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mpas-developers@mailman.ucar.edu">mpas-developers@mailman.ucar.edu</a>
<a class="moz-txt-link-freetext" href="http://mailman.ucar.edu/mailman/listinfo/mpas-developers">http://mailman.ucar.edu/mailman/listinfo/mpas-developers</a>
</pre>
</blockquote>
<br>
</body>
</html>