RE: [election-services] Language Binding Generators

["David RR Webber \(XML\)" <david@drrw.info>]

Rich,

 

That's one way of looking at it the counter position goes something like this:

 

1) Having a set of schemas numbered by group and function is a powerful plus in the way EML is architected and organized - I know what the 100, 200, 300, 400, 500 and 600 series do.

 

2) XMLBeans is just a tool - normally we do not make specification changes to accommodate tools - that sets an ugly precedent.

 

3) Versioning is a challenge for static content handlers like XMLBeans that generates fixed memory structures.  Obviously the dynamic XSLT style *any* handler approach is more flexible.  So - whether I call a root element something like EML, or VotingRecords or Foobar - XMLBeans will still have an issue when it comes to V7 release - since that will be using those same root element names so now that will be conflicting.  It does have ways to overcome this - and we should simply refer developers to those - the folks over on the XMLBeans dev list will be happy to explain (BTW - I'm on the XMLBeans dev list!).

 

4) Making this change would have extreme knock-on ramifications for the documentation and associated details that will add considerably to the effort need to produce the EML V6 voting package for OASIS.  Not only that - but the same thing for people who have implemented V4 and V5 already - code wise.

 

Thanks, DW

 

 

-------- Original Message --------
Subject: RE: [election-services] Language Binding Generators
From: Richard J Cardone <richcar@us.ibm.com>
Date: Thu, January 22, 2009 1:16 am
To: "EML TC" <election-services@lists.oasis-open.org>


David,

I don't remember exactly how customized name mapping is done in Xmlbeans, but I think it involves the use of a poorly documented configuration file.  I also believe JAXB provides a way to specify non-default class name mappings, but again I try to avoid these complications whenever possible.  The v6 effort offers us an opportunity to make EML schemas generally easier to use with code generators.  My argument for considering at this time a change to the top level element names in EML schemas goes like this:

1. The top level element in an XML document should reflect the contents of that document.  For example, it's reasonable for the top level element in a purchase order document to be <PurchaseOrder>.  Likewise, it's reasonable for the top level element in an EML ballots document to be <EMLBallots> (or something similar).  In a sense, it's misleading that dozens of different documents start with the <EML> element even though their content and use are unrelated.  

2. The use of language binding generators is simplified when different schemas define different top level elements.  These generators are valuable because they remove much of the drudgery and pitfalls of parsing, reading, and writing complex XML documents, especially when compared to technologies like SAX and DOM.  By using different top level element names, generators can use their default name mapping algorithms without causing name conflicts.  Using the default name mapping reduces the burden on developers and generally simplifies applications.  Also, different generators are going to have different levels of support for name customization and it would be nice to avoid the whole issue.  

3. If the installed base of EML 5.0 isn't prohibitively large, then breaking upward compatibility to EML 6.0 by renaming top level elements to be more descriptive may be worth it.  If we don't do it now, it probably will never get done.  I don't know if any other v6 change breaks upward compatibility (i.e., requires code changes in applications that use EML 5.0), but the level of near-term disruption needs to be weighed against long-term payoff.

Rich