BeerXML 2.0 schema proposal

[AntonW]

Hi songstre,

I noticed some traffic on the AHA list so maybe that will be converted to enthusiasm to wrap up the working draft of version 2.0 of BeerXML.  Unfortunately I haven't had time to work on this project in several months and will need to perform a fresh review to help me get back up to speed.

When version 1.0 was started there probably wasn't a rich collection of XML validation techniques like today.  But with validation against an XML schema, the checking becomes automatic and the guesswork about how to handle malformed data is somewhat reduced.

Since QBrew is freely available in the freebsd ports tree, I was hoping to take a closer look at updating it's source code to support version 2.0 of BeerXML.  If you or others have questions or comments about the working draft of BeerXML 2.0x please post them and I'll try to get back to you as soon as possible.

Thanks,
-Anton

[AntonW]

Ok, here are some additional thoughts regarding the 2.0x schema proposal as it stands now.

These I would recommend as changes that should be made:

Each name of the XSD should list the major version number, so BeerXML.xsd would become BeerXML.v2.xsd, this would allow multiple major versions to be in the same directory.

course_grind should be added back (as an optional element) to FermentableType, since it isn't always the case that Fine - Course = Fine_Course_Diff.  Most likely there is a supplier-specific correction factor that is being added.

These changes require more investigation:

In FermentableBase, should the <type> element containing 'extract' choice be changed to 'liquid extract', in similar fashion to the 'dry extract' choice value?

In FermentableType, should inventory amount be changed to allow amount_as_volume (only mass units are supported currently)?

In MiscellaneousBase (use_for) and YeastType (best_for), should we change these element names to <recommended_use> for greater consistency?

And a more general question:

Should we split the FermentableType record into three separate record categories, specifically grain (with most of the current elements in FermentableType), extract (with only a subset of FermentableType elements), and adjuncts (also supporting a FermentableType subset).    As the schema stands now, the majority of elements are optional to allow for flexibility for extract and fermentable adjuncts.  But if we break those out into separate record types, overall we should have more consistency between categories.

I was thinking grain has already been well-specified.  Extract should cover all aspects of both dry and liquid malt extracts.  And adjunct would cover sugar, fruit, honey, molasses, and anything else (other) than can make a meaningful contribution to the overall gravity of the beer.

Any thoughts?

-Anton

[randyrob]

Hey Guys.

just having a play with BeerXML v2.06

and one of the example recipe's ("MedievalAle.xml") provided with the BeerXML v2.06 fails validation?



Cheers Rob.

[AntonW]

Hi Rob,

Please open the MedievalAle.xml file and update the <style:style_letter> element from ' ' (space character) to 'A'.  It seems that the XML processor within BrewMate is ignoring whitespace, which is causing the failure in the validation.

Please let me know if that doesn't fix the validation problem.

-Anton

[randyrob]

Hey Anton,

Yes the file passes validation perfectly now! thanks for that.

I end up writing a little standalone program to check if BeerXML file validate http://www.brewmate.net/beerxml/BeerXML-Validation.exe

that uses the XSD's available on your site, but it seems every BeerXML v1 file i throw at it fails validatation for some reason or another

does anyone else use the BeerXML v1 XSD's?

Rob.

[AntonW]

Hi Rob,

Excellent - glad to hear your BeerXML v2 recipe succeeded to validate!  With BeerXML v1 there wasn't an official set of XSDs released by the authors of the specification, just the document that outlined the elements that should be populated.  I reverse engineered the set of v1 XSDs based on my understanding of the document (others have done this independently as well).  Unfortunately it's quite difficult to maintain compatibility across implementations without a mechanism as powerful as schema validation.  And I don't know of anybody that is using the v1 XSDs since they are not officially part of BeerXML ( even though I have found bugs in BeerXML v1 programs with them :^).

-Anton