[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [election-services] Re: VIP/EML CONVERGENCE
-------- Original Message --------
Subject: [election-services] Re: VIP/EML CONVERGENCE
From: Richard J Cardone <email@example.com>
Date: Wed, July 23, 2008 11:30 am
The idea of a U.S. localization of EML that you raised in your 7/18 posting sounds like a good strategy. Simplicity is probably the most useful design characteristic of any technology aimed at a wide audience. The U.S. Post Office addressing standard (http://pe.usps.gov/cpim/ftp/pubs/Pub28/pub28.pdf) might be a good starting point for the address localization portion of the work.
I have a question with regard to how a VIP/EML converter would work or, more precisely, how VIP schema elements are associated with EML schema elements. In the draft document, EML-VIP Compare.docx, attached to your 7/16 note, you take a first stab at matching VIP elements to EML elements. It seems that individual VIP and EML elements may coorespond to each other, but their contexts do not. For example, the election_type child element of the VIP election element is matched with the ElectionType element in EML's 340-410-430-include-v5-0.xsd file. In that schema, the ElectionType element is a child of Contest, which is a child of Election, which is a child of BallotStructure. It seems that ElectionType cannot be easily used without its enclosing context.
Another example along the same lines is the matching of the statewide child element of the VIP election element with the EML ContestOther element, which I interpret as the xs:any namespace="##other" child element of Contest. Contest is defined in various ways in a half dozen EML schemas, so I'm not sure exactly which definition is being referenced. In any case, Contest is not a top-level element or type in the schemas in which it appears, so I wonder how the enclosing contexts will affect VIP/EML element matching.
As a final example, OutgoingGenericCommunicationStructure as defined in emlcore-v5-0.xsd requires that at least one Voter child element be defined, which seems to be an unnecessary burden if OutgoingGenericCommunicationStructure is matched with the name child element of the VIP source element. This too seems like a context problem, though here it's not an element's enclosing EML context that complicates matters, but it's enclosed context.
There's a good chance that I missing something basic, so I don't mind being set straight. If my observations, however, do raise an issue, then VIP/EML convergence might be more complicated than we first thought.
John Borras <firstname.lastname@example.org>
07/16/2008 11:01 AM
To Aaron B Strauss <email@example.com>, Doug Chapin <firstname.lastname@example.org>, "David RR Webber \(XML\)" <email@example.com>, firstname.lastname@example.org, email@example.com, Richard J Cardone/Watson/IBM@IBMUS, firstname.lastname@example.org cc Subject VIP/EML CONVERGENCE
Thanks to all for the productive call earlier. Attached as promised is my initial analysis of the VIP and EML data elements overlap.
I am looking to my colleagues, particularly Paul and David, to confirm my analysis including suggestions for exactly how we would implement the VIP requirement using EML. The prime area of USA address handling within EML needs particular consideration as do things like Ballot Drop and Campaign Issues. From this we can draw up a list of possible EML enhancements and then the OASIS committee can decide how and when to deal with them.
Recognising that you all have day jobs to do as well but it would be good if we could complete this tranche of work within the next couple of weeks. So replies by the end of July if possible please.
M. +44 (0)7976 157745
Not happy with your email address?
Get the one you really want - millions of new email addresses available now at Yahoo!
[attachment "EML-VIP Compare.docx" deleted by Richard J Cardone/Watson/IBM]