Proposed Extensions to Roasting Data XML

[N3Roaster]

Once work on merging an externally developed patch for handling non-temperature measurements and support for hardware capable of generating such measurements is complete, XML serialization of roasting data will have the following structure:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE roastlog3.0>
<roastlog>
    <temperatureseries name="Bean" />
    <controlseries name="Gas" />
    <noteseries name="Note" />
    <roast>
        <tuple>
            <time>00:00.000</time>
            <temperature series="Bean">265.8</temperature>
            <control series="Gas">99</control>
            <annotation series="Note">Start</annotation>
        </tuple>
    </roast>
</roastlog>

There can be any number of *series elements that describe the data that will follow in the roast element and while each tuple element must contain a time, it need not contain data for every series. In particular, the annotation elements will not be present for most tuple elements.

This is a somewhat limiting format, particularly if there is a desire to make useful tools that are external to Typica. A number of changes could be made to the format to make it more generally useful.

• Unit data. At present temperature data is considered to always be represented in degrees Fahrenheit. While Typica is unlikely to change this default representation, the unit should be stated explicitly in the tempseries element. This could be done by creating a unit attribute with a value of "F", "C", "K", or "R" to indicate that measurements in that series are presented as degrees Fahrenheit, Celsius, Kelvin, or Rankine respectively.
• The separate tempseries and controlseries elements and their temperature and control elements should probably not be separate. The introduction of a more generic measurementseries and measurement elements could replace these. Again, attributes in the series declaration would be required to better describe the data.
• Control series data is currently considered to be unitless. This should be extended to common types as support is added in Typica for hardware generating measurements in different units. Switching away from specialized elements will make it easier to allow appropriate unit conversions in all cases.
• There is no data about the batch aside from recorded measurement data and annotations associated with particular measurements. It should be possible to preserve the name of the roasted coffee, the green coffee used, weights before and after roasting, any target roast profile that was used, annotations that apply to the batch as a whole, who roasted the coffee, environmental data, and possibly other information as well. Consideration should be given on how to standardize this batch data. This sort of information will also be required in a number of other areas of interest, so getting this right would be broadly useful.
• Namespace. The roastlog element should have an XML namespace to facilitate embedding roasting data in other XML documents.

There are also some areas where the behavior of Typica could be improved in generating these files to improve file size and loading times. At present, every measurement in every data series is preserved, but it would be useful to have as an option the ability to preserve only those measurements in a series where the new value differs from the earlier value. This would greatly improve performance where multiple unsynchronized devices are in use. It would also make it easier to handle annotations that are tied to a time without a measurement which would perhaps make it easier to allow editing annotations in the table view in Typica, which some people seem to want to be able to do.

[N3Roaster]

Batch data such as what would be recorded in the roasting_log table would be useful for reconstructing missing data in the event that something causes inserts to that table to fail.