RE: [election-services] Language Binding Generators

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

Rich,

 

I thought I had solved the XMLBeans issue with the static attribute values.  I know it can key off these to load the right mapping at runtime in the Java - and of course when it builds the map in the first place - you can choose to name that mapping output internally however you want to.  Its the same problem as with versioning of any schema - the root tag name is the same - but the maps different.  XMLBeans has mechanisms to handle this - but having static attribute values for Id and Version - obviously a big plus there.

 

My preference is to stay with the Id=number method - because its enshrined everywhere in EML.  I also picked Id as the attribute name to ensure least impact compared to EML v5.

 

Now you've pointed out those other Id uses we could consider aligning those thru a single consistent typing. I think that should be our next move here.

 

Thanks, DW

 

 

-------- Original Message --------
Subject: [election-services] Language Binding Generators
From: Richard J Cardone <richcar@us.ibm.com>
Date: Wed, January 21, 2009 2:23 pm
To: EML TC <election-services@lists.oasis-open.org>


Hi,

I noticed a couple of things regarding the proposed EML v6 attribute named "Id", which appears as a required, fixed value on top-level elements on many v6 schemas.  

First, an Id attribute that uses different types is also defined on various elements in emlcore-v6-0.xsd.  For example, the CountMetricStructure element defines an optional Id attribute with type xs:token; EventQualifierStructure defines an optional Id attribute with type xs:NMTOKEN; and VoterIdentificationStructure defines an optional Id attribute with type xs:anySimpleType.  In addition, Id is also used as a subelement name in the same schema file (see ProposerStructure).  This reuse of the same name in different situtations may be confusing.

Second, as far as accommodating language binding generators, consider the case of Java language binding generators like Apache Xmlbeans or JAXB.  These generators read schema files and generate Java class libraries that allow XML documents that conform to those schemas to be conveniently read and written.  The names of the generated classes are taken from the element names defined in the schemas.  Unfortunately, most EML 5.0 (and 6.0) schemas define <EML> as their top level element.  When class libraries are generated for more than one schema, name conflicts occur when the generator tries to create multiple classes named "EML".  

I don't think the new "Id" attribute solves the language binding generator problem.  One direct solution to the problem would be to define unique top level elements in each schema.  For example, we could define <EMLBallots> as the top level element in 410-ballots-v6-0.xsd and <EMLCastVote> as the top level element in 440-castvote-v6-0.xsd.  Java applications that use both of these schemas can generate binding classes without experiencing name conflicts.

On a semantic level, one could argue that XML documents that represent different data, and that conform to different schemas, should have different top level elements.  Having unique top level elements allows applications to easily determine a documents type from its top level element.  Of course, the proposed Id attribute also satisfies this document identification problem.

Rich