Discussion on project-goals-and-structure

[Skylar]

Is the goal to implement v1 of the spec or v2 of the spec? I know 2 is
still under development but it has much more defined schemas and has a
much better API-feel.

[Ryan Thompson-Jewell]

Good question. There are many apps that export BeerXML v1 and their compliance to the v1 spec varies widely.
A programmer writing an app to import or export BeerXML most likely will have to deal with v1 and v2 xml.  I'm not that familiar with the changes in v2. If its backwards compatible or the differences are minor then I could see us coding for v2 then v1 phase 2. Especially since the SDK would most likely be used for new development.  I am open to what ever the group wants.

--
Ryan Thompson-Jewell
R.A.Z.E. homebrew club - www.razebrewing.com
My blog: brewcoder.blogspot.com

[Skylar]

From what I understand they aren't very backwards compatible.The root
problem is that the folks who created version 1 did not create an XSD
to enforce a specific implimentation. Without the schema any element
could be added to the XML document by the application making an API
difficult (we would have to throw exceptions when we hit a non-
standard element). The schema allows the API to validate the whole
document before it even begins converting it to OO.

Latest v2 proposal: http://www.speakeasy.org/~antonw/beer_xml/BeerXML_v2_05a.zip

On Aug 28, 9:48 am, Ryan Thompson-Jewell

[Ryan Thompson-Jewell]

Well as a developer I still may want to import non-compliant xml to the best of my ability since I can not control the source and most of the times the user of my app can not either. A exception telling them the XML is not compliant would mean nothing to most brewers. I think this is where the SDK can fill some gaps. I want to give the programmer consitant objects to deal with and prevent a lot of "is this element defined" code.

For me this saves a ton of time for the developer by not having to write exception code and focus on other aspects of their app.
If our SDK can take the worst xml and make consistant objects that would be great. Maybe there needs to be some meta data in our objects that the developer can use to rank compliance. Some example methods might be.

isSchemaCompliant(): boolean - to tell them if it met the schema
getSchemaScore(): int  - maybe a score on how bad the data might be. They can then choose to import based on the score...
getSchemaErrors(): struct/map - what elements are missing or bad.

Just some thoughts. The above mehods could be on the "recipe" object or part of a validation object.
--
Ryan Thompson-Jewell

[Skylar Sutton]

I'm ok with that approach. I would suggest some sort of top-level object like "BeerXMLDocument" to attach those to and contain the subsequent arrays of objects.

[Skylar Sutton]

Another thought for discussion... what if we make the SDK work with only the latest version of BeerXML, and make step one of the deserialization be an "upgrade process" to get it to the current version. Step 2 would be the convert from current version to objects.

This would set us up for any future versions of BeerXML (i.e. we would write a v1->v2 converter and a v2->v3 converter)... but have the downside of always saving document changes in the most current format.

 - Skylar

[Ryan Thompson-Jewell]

Interesting idea. I wonder if xslt would be robust enough to do that or might have to help out with code for poorly compliant files.