BeerXML 2.0 Definition

[jvetter]

Thanks for the input. I'm sorry to say I haven't been giving BeerXml much attention lately

Post a list of what you think should be changed and we can discuss it.

Thanks,
Jaime

[KLuwak]

Here are some things which I might do differently:

• In the <recipe> record, I'd make "efficiency" optional.
• In the <fermentable> record, I'd make "color" optional.
• In the fermentation_stages, I'd either make "temperature" optional, or give some way to specify approximate values.  I can't keep the temperature constant to within 1 degree over the course of fermentation, and I don't like the idea of having to write incorrect information.
• It might be nice to able to specify fermentable amounts by volume.  Many recipes use volume measures, especially for conditioning sugars.  It's possible to convert to mass, but it's extra work, since the density of corn sugar isn't something I know off the top of my head.
• I'd like to able to specify which fermentables are added to which stage
• I'd like to be able to specify bottle vs. cask conditioning, and whether forced CO₂ was used.

Even though that looks like a long list, I'm really happy with BeerXML!  What do you think about those ideas?

[AntonW]

Hi,

You've brought up some good points KLuwak - and unfortunately I'm overloaded at the moment so I'll have to defer any appropriate changes to a later day (or a later week it seems).  However it looks like the efficiency is optional in the recipe record (the documentation may be off a bit - I need to spend a boatload of time to update the docs and the BeerXML converters to match up with the XSDs):

         <xsd:element name="efficiency" type="PercentType" minOccurs="0" maxOccurs="1" />

The color element is required for fermentables, but if the color value wasn't known for the fermentable then a value of 0 deg L could be entered and it wouldn't act as color contribution.  Additionally a value of 0 would act as a placeholder so if the value could be determined or an estimate made then it could be added in later.  The problem with making this element optional is that a lot of grains are only distinguished by their color... But more on this below.

For the temperature within the fermentable_stages element, I think the intent of the value was to enter the average temperature over the time period specified.

Would you agree that measuring fermentables by volume generally happens with fermentables that are not grain?  We might be able to split out the grain as a separate fermentable entity with a color and with measuring additions by weight.  We then could have the rest of the fermentables measured by volume or by weight and have color as an optional element.  It would add more complexity to the overall system but the solution would be worth the cost of investigation.

For recording which fermentables are added to which stage, that information was going to be captured in a session record (which would combine a recipe with the session-specific steps of it's execution).  It would also contain the specific conditioning information as well.  Unfortunately I haven't had the time or energy necessary to get that record type rolling.  If you'd like to list any additional elements you'd like to see in a session record we can talk more and maybe get a rough draft added to the other schemas.

Keep sending in those great ideas!
-Anton

ps.  If you have a chance, check out the BeerXML with namespaces and let me know if it's crazy or a good idea (or both!).  It's located here:
http://www.speakeasy.org/~antonw/beer_xml/BeerXML_v2_05a.zip

[KLuwak]

You're right that efficiency is optional.  I'm not sure where I got the idea that it was required.

I'm not a fan of using 0L as a color placeholder value; that's effectively like making it optional, but without the clarity.  If the value's unknown, I'd rather know that it's unknown, if that makes sense.  What happens if we make it optional?  If the user wants to specify a grain for which color is the distinguishing feature, they're still able to do so.

Is the rationale to support automatic analysis?  So that, say, your program could read any BeerXML2 file and output the expected color?  There's something to be said for that, because the program doesn't have to do any manual verification -- if the file complies with the schema, you know it has all the required information.  I'm wondering if it might make sense to define two variants?  There could be a "Strict" or "Complete" which must provide all the information you could ask for, and a "Lax" in which only the bare minimum is required.  Does that make sense, or is it just making extra work?  It's hard to come up with a format that's equally appropriate for a beer program's database and a hand-entered note.

I'm not 100% sure I understand the "session record" idea, but I think I like it.  Would that be a description of a specific brewing event, as distinct from the general instructions?  I can picture including OG and FG measurements, temperature recordings, and notes at various stages.  I'm not sure about things like substitutions -- maybe it should just be a different recipe in that case.  That's a question of beer philosophy, I think.  If the session records don't include substitutions, maybe the recipe should allow a way of specifying alternates?  Many written recipes will say "Wyeast XXX or White Labs YYY" for example.  I don't have any strong preferences on this.

[AntonW]

Hi,

For color (and for BeerXML2 in general) the rational is to follow the recipe format provided in most publications, which generally state the color of the grain being added in the recipe.  When an element is made optional, it moves the complexity from a well-formed and normalized mechanism (XML) into the proprietary error handling routines of each program.  This results in each program approaching the problem differently, which (unfortunately) has a tendency to cause problems when these recipes are shared between several different beer-making programs.  With the current approach all fermentables are handled as grains, which probably needs further scrutiny to develop a more elegant solution.

Brewing session records are collections of real data containing the observed/measured values when a recipe is used to create a beer during a brewing session.  On the other hand, the recipe should contain only the estimated/ideal values to collect ingredients and a basic procedure to follow to yield the target beer as a result. For substitutions, the collection of the actual ingredients used to create the beer would be listed in the session data.  A session would link to (or encapsulate) the recipe data used, with the suggested ingredient list available in the actual recipe.

-Anton

[Oud Schoten]

I didn't follow the discussion , but is there perhaps Final version i can use?