Re: [election-services] Re: VIP/EML CONVERGENCE

Rich

Thanks for your very useful observations. I accept my initial analysis of VIP/EML elements may have been a little too simplistic but as I see it the VIP project is looking to handle a small subset of the data held within a State's EMS and what I was attempting to show was that we have the ability within EML v5 to match that subset of data. On our recent call we did accept we might have to produce some additional messages to meet the VIP requirement but it should only be about re-packaging our EML elements rather than creating new ones. In those new messages we would probably need to draw down the necessary context data as well. You may be right however that this is a little bit more complicated than my usual optimism would hope for .....-)

What I would suggest is that if we produce a USA localisation of EML then these additional messages are part of that output and we can decide at a later date whether we want to put them into EML v6 for global use.

Regarding the US Post Office Address standard, from a quick read it looks to me that if we produce a 2/3 line text address using CIQ as Peter and David have suggested then we should be pretty close to that standard. I suggest we let David finish his current exercise and then we can see how close a match it is.

Regards
John

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

----- Original Message ----
From: David RR Webber (XML) <david@drrw.info>
To: Richard J Cardone <richcar@us.ibm.com>
Cc: election-services@lists.oasis-open.org
Sent: Wednesday, 23 July, 2008 6:18:53 PM
Subject: RE: [election-services] Re: VIP/EML CONVERGENCE

Rich,

This is all very helpful.

I have half the schemas done in terms of producing an automated subset based off an initial "wantlist" and ability to document the crosswalk to VIP in annotations we can then all share together.

Need to slog thru the rest of the complete set in next couple of days - then I can post these to the group.

Once we have this agreed - then the editor tool I'm using can produce the new subset schemas that conform to that for US - and the documentation - and working test case examples.

Hopefully we can then all be clear on how this all fits together!?!

Back to the XML...

Thanks, DW

-------- Original Message --------
Subject: [election-services] Re: VIP/EML CONVERGENCE
From: Richard J Cardone <richcar@us.ibm.com>
Date: Wed, July 23, 2008 11:30 am
To: election-services@lists.oasis-open.org

John,

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.

Regards,
Rich

John Borras <johnaborras@yahoo.co.uk>
07/16/2008 11:01 AM

To
Aaron B Strauss <aaronbs@gmail.com>, Doug Chapin <dougchapinjr@gmail.com>, "David RR Webber \(XML\)" <david@drrw.info>, paul.spencer@boynings.co.uk, pzelechoski@essvote.com, Richard J Cardone/Watson/IBM@IBMUS, joehall@gmail.com

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.

Regards
John

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

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]

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

election-services message