RE: [election-services] Language Binding Generators

[Richard J Cardone <richcar@us.ibm.com>]

David,

I copied your last response below and
inserted in-line comments.  You make some good points and I think
the essential issue is becoming clearer.  

Rich  
--------------------------------------
David's 1/26 Posting --------------------------------------
DW> Richard,
 
DW> OK - but this still does not answer
my basic observation.
 
DW> So we rename everything EML110ElectionEvent,
EML120, EML130 etc.
 
DW> Everyone builds their V6 language
bindings.  Then along comes V7 of EML and guess what - everything
is still called EML110ElectionEvent, EML120, EML130 etc - so we're back
to square one - the language binding tools still get confused because more
than one thing is called the same name (remember they can encounter both
V6 and V7 XML instances potentially in the same election from different
devices.
RC> The above comment appears to be
an argument against using language binding generators with EML, though
from your next comment I don't think you meant that.  But to your
point, it's easy to imagine applications that would never need to know
about more than one version of EML during any execution.  In the case
of applications that do support multiple EML versions at once, the existing
version attribute in top-level elements provides a workable solution when
coupled with the technique in your next comment.        
 
DW> And we already have the notion of
a single unified parser - handling top level EML and then determining from
the Id which content type they are parsing.  I know on my last project
we built this for XMLBeans without needing any additional schema devices.
RC> I would be interested in hearing
about the technique you used in your last project, which I'll dub as the
2-pass parsing approach (the first pass determines which static parser
to use, the second pass uses that static parser).  I'm especially
interested in (1) exactly how you specified the package and class names
that were generated and (2) how jar files were generated to avoid excessive
amounts of duplicate code.  Most important, did your last project
also have a top-level element like <EML> that was defined differently
in many different schemas?  My concern isn't with using the Id attribute
to determine the document type, but rather with the need to custom configure
generators to avoid name conflicts when the same top-level element name
is used in multiple schemas. 
 
DW> Fundamentally I'm not convinced
we're buying anything here.  I'd be the first to jump on needing to
make things easier - but right now I'm not seeing any.  The binding
tools like XMLBeans are fully capable of handling this - and by making
software developers right up front deal with this issue in their implementations
- we're actually helping them build correctly and ensure their software
is version enabled.
RC> Here's what we buy by defining unique
top-level element names:  the ability to automatically generate a
static EML parser without name conflicts for each version of EML.  If
the 2-pass approach you mention above solves this problem for Xmlbeans
in a reasonable way--great, but the issue still exists for all other generators.
 
 
DW> I prefer the simple and clear -
and if people want to build supporting additional schema for language bindings
- they can do that - I just don't see that is our job.  Also - remember
- any new schema has to be documented - and reviewed thru the OASIS process
- and I'm not sure a schema purely to help language binding is something
we're going to be able to justify.
RC> I see your point with regard to
adding another schema.  As far as simple and clear goes, I still believe
defining <EML> differently in some 28 schema files tends to make
EML semantics less clear.  If the overloaded <EML> definition
didn't complicate the use of language binding generators, the point would
be academic and reasonable people could differ.

RC> My current thinking is this:  Both
the Id attribute approach and the unique top-level element name approach
allow a 2-pass parsing technique to select a static parser to use for a
given EML document.  With either approach, we determine the content
type of a document by inspecting its top-level element.  The unique
top-level element name approach also allows language binding generators
to avoid name conflicts within an EML version with no extra work for developers.
 Arguably, this approach also makes EML semantics easier to understand.
 So if our choice for v6 is to either add the Id attribute or to use
unique top-level element names, why not go with the latter?    
    
 
DW> Thanks, DW