Re: VIP/EML CONVERGENCE

[Richard J Cardone <richcar@us.ibm.com>]

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]