OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

election-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [election-services] Language Binding Generators


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.  

-------------------------------------- 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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]