Re: [election-services] Fw: [election-services-comment] Comment on EML Structure

[John Borras <johnaborras@yahoo.co.uk>]

Paul

 

From memory this is the first time this sort of approach has raised its head, and my initial reaction was fine if that's what a particular developer wants to do then I don't see we as a TC should say no can do.  I don't think it undermines EML in anyway unless I'm missing something?

 

What I would like the TC to give though is an opinion of the strengths and weaknesses of using this type of approach and where it could be beneficial to use it.  Any views on the answers to those questions?

 

Whether we want to include it as part of EML v6.0 is another question and we can debate that later.

   

Regards
John

M. +44 (0)7976 157745
Skype: gov3john

----- Original Message ----
From: Paul Spencer <paul.spencer@boynings.co.uk>
To: John Borras <johnaborras@yahoo.co.uk>; EML TC <election-services@lists.oasis-open.org>
Sent: Friday, 9 May, 2008 12:01:39 PM
Subject: RE: [election-services] Fw: [election-services-comment] Comment on EML Structure



John,

 

I think there are two issues here. All EML messages start with the EML element. But inside this, the main meat of each message type has a different top level element. The rest of the stuff inside the EML element is envelope data. So using the tools on the lower level element may get round this issue. Personally, I prefer all EML messages to start with an EML element.

 

I think there is a stronger case for changing names to make them unique in cases such as the "Result" one quoted.

 

Regards

 

Paul

 

 

-----Original Message-----
From: John Borras [mailto:johnaborras@yahoo.co.uk]
Sent: 07 May 2008 14:43
To: EML TC
Subject: [election-services] Fw: [election-services-comment] Comment on EML Structure

Please see the Comment below received via the TC website.   I've added this request to our v6.0 Wishes List and also added a note about the utility to our WIKI.  Whilst we don't need to make any concrete decisions immediately about the validity of this request, I'd welcome any initial thoughts about it and the consequences should we eventually decide to include it in the next release.

 

Also just to keep you in the picture, work on our submission to ISO is still progressing and agreement has been reached that the JTC1 committee will take us on board.  A note about this and the ensuing procedures should be issued by Jamie Bryce in the near future.
 

Regards
John

M. +44 (0)7976 157745
Skype: gov3john

----- Forwarded Message ----
From: Richard J Cardone <richcar@us.ibm.com>
To: election-services-comment@lists.oasis-open.org
Sent: Tuesday, 6 May, 2008 5:22:25 PM
Subject: [election-services-comment] Comment on EML Structure

As a new user of EML 5.0, I wanted to run the EML schema files through
Apache Xmlbeans or JAXB to generate Java bindings for EML documents.  The
generated Java classes would provide a higher level interface than that of
SAX or DOM, both of which force applications to deal directly with XML.
Unfortunately, many of the EML schema files define the same top-level
element, <EML>, which complicates the use of code generating tools.

For example, 440-castvote documents and 410-ballots documents are both
required to start with an <EML> element.  Applications cannot easily
generate language bindings for both types of documents together because
name conflict errors will occur during generation.  The language bindings
could be generated separately for each EML schema, but the total size of
generated code could easily get out of hand because of the many
definitions duplicated in each library.  In addition to the <EML> name
conflict, there are other name conflicts that cause problems, such as the
definition of <Result> elements in 120-interdb and 520-result.

It would be nice if EML 6.0 could better accommodate the use of automated
tools like language binding generators, but maintaining backwards
compatibility might be a challenge.  In the meantime, I wrote a utility
program, EML50Combine, that allows users to select which EML 5.0 schema
files should be merged into a single schema file.  After EML50Combine
runs, the combined schema file contains the definitions of all the
selected EML schemas.  The combined schema file can then be inputted into
a language binding generator like Apache Xmlbeans to generate classes for
all the definitions it contains.

Documentation and code for EML50Combine can be found at
https://sourceforge.net/projects/eml50combine.

Rich Cardone

---

Sent from Yahoo! Mail.
A Smarter Email.

---

Sent from Yahoo! Mail.
A Smarter Email.