Next in thread →
Next in month →
RE: [election-services] RE: VIP/EML CONVERGENCE?
John,
I have
kept out of this since that is about the time I will be starting a new contract
overseas. I will attend if I can. I may even get a chance to catch up with what
has been going on next week.
Paul
-----Original Message-----
From: John Borras
[mailto:]
Sent: 18 August 2008
16:22
To: EML TC
Subject: Re: [election-services] RE:
VIP/EML CONVERGENCE?
Is everyone happy to make the teleccon on 2nd rather than 1st Sept
to accommodate Peter please?
Regards
John
M. +44 (0)7976 157745
Skype: gov3john
-----
Original Message ----
From: "Zelechoski, Peter"
<>
To: David RR Webber (XML)
<>; John Borras <>
Cc:
EML TC <>
Sent: Monday, 18
August, 2008 2:53:07 PM
Subject: RE: [election-services] RE: VIP/EML
CONVERGENCE?
David / John -
September 2 is the only day in the first month of
September that I will be available.
- Peter
From: David RR Webber (XML)
[mailto:]
Sent: Friday, August 15, 2008 9:56
AM
To: John Borras
Cc: EML TC
Subject: RE:
[election-services] RE: VIP/EML CONVERGENCE?
John,
OK - sounds good. Let's see what people's time looks like beginning
of Sept' then.
Are you thinking 10am EST, 3PM UK time?
Also - I would like to try and use the Adobe Webinar tool that OASIS has
free access to - that way I can walk folks thru the precise details on all
this.
I'll try a dry run with the Adobe next week - then once we have a firm
date/time I'll send out a meeting place invite to everyone.
Thanks, DW
--------
Original Message --------
Subject: Re: [election-services] RE: VIP/EML
CONVERGENCE?
From: John Borras <>
Date:
Fri, August 15, 2008 5:25 am
To: "David RR Webber (XML)"
<>
Cc: EML TC
<>
David
That sounds like an excellent plan but a couple of minor adjustments if
I may please.
First can we run this past TC members before we show the VIP guys
please. So let's have a TC telecon early Sept then one with VIP guys
following that.
Secondly can we have a go at the new message before we talk to the
VIP guys. We should be able to agree this on the TC telecon and then
have a strawman ready for the VIP telecon.
Do you want to commit to a date in first week of Sept for the TC
telecon so we can get dates in diaries? Early that week is OK
for me, can't do end of week.
In the meantime I'll drop the VIP guys a note telling them we're still
on the case to keep them sweet.
Thanks again for your efforts....-)
Regards
John
M. +44 (0)7976 157745
Skype: gov3john
-----
Original Message ----
From: David RR Webber (XML)
<>
To: John Borras
<>
Sent: Thursday, 14 August, 2008 5:10:53
PM
Subject: RE: [election-services] RE: VIP/EML CONVERGENCE?
John,
OK. Next few days is really tough. Let me try here in an
email...
I'm seeing we are closer than we think - but the issue is that seeing
that through all the schema syntax is not easy.
What I'm looking to do is to use the tools I've built for DHS/DOJ to
apply those techniques to EML.
This allows you to get a handle on your own subset of EML easily -
with the address information from CIQ particularly tamed - but also the
ability to manage the EML portion too - select and tailor that as
needed. I can give people a first cut at that they can work
from.
That gives us a simple template for US use distilled from existing EML
5.0 messages.
Now the next peice is figuring out what the VIP needs that are
new. I think we got to the point of seeing we need a new message - to
cover that - and obviously there we want to re-use our existing vocabulary
and invent as few new elements as possible.
We can certainly produce a strawman for that new message and float that
with the VIP folks.
So - that is the plan. I've been having to work at Martin Roberts
pace though on the toolkit. He just got back from holiday. So I
was able to get much tested this week. I still have a couple more
small issues to fix - and Martin is going to do a new release on this coming
Monday.
That will get the toolkit finished. Then I'm out 19th/21st on
business trip. So when I get back I can finish up the current EML
testing and publish those magic US use templates and documentation for them
and then think about the new EML message we need. If you want to setup
a next meeting for early in September - then I think that will work.
In summary - plan is:
1) Create set of VIP templates for EML from the existing EML schemas
(i'm part way into this - need to finish testing).
2) Generate documentation and sub-set schemas for those
templates (the toolkit does that automatically)
3) Share the subset with VIP folks - work those till we're happy those
are OK.
4) This gives you the blue-print then for using EML for VIP and USA
EML.
5) Develop new message using EML 5 core - for extended peice VIP needs
on registration/polling place side.
Here's the tutorial I've developed on doing this subset from EML (my
plan is the VIP folks can review all this themselves once I give them a
jumpstart):
http://www.drrw.net/projects/DHS/xsd-2-cam/XSD%20and%20jCAM%20tutorial.ppt
Thanks, DW
--------
Original Message --------
Subject: Re: [election-services] RE: VIP/EML
CONVERGENCE?
From: John Borras <>
Date:
Thu, August 14, 2008 3:58 am
To: "David RR Webber (XML)"
<>
David
Can you spare a few moments to talk via Skype about this
please. It's just I'd like to understand exactly what you're
proposing we do now for VIP. I'm free virtually anytime for a
call.
Regards
John
M. +44 (0)7976 157745
Skype: gov3john
-----
Original Message ----
From: David RR Webber (XML)
<>
To: John Borras
<>
Cc: EML TC
<>; "Zelechoski,Peter"
<>
Sent: Wednesday, 30 July, 2008 6:54:08
PM
Subject: RE: [election-services] RE: VIP/EML CONVERGENCE?
John,
OK - that's a big mis-read on what I'm saying here!
The EDXL approach to addresses covers off all three ways to do
it.
That means for now - today - we can use POSA - plain-old street
addresses.
BUT - it also gives us the other two ways of doing it - GPS and map
references - those will be really important in areas (worldwide) where
there are NO streets!!! E.g. - everyone south of the river and north
of the mountain ridge.
Yes - I know we need to get one or two states on-board for a limited
pilot - understand what the real world looks like today.
BUT - what we really need here is to MODEL the data first. So
we have an understanding of the needs - and the relationships. Once
we have everyone agreeing on that - then we can build XML to suit - or
re-use existing XML with confidence.
What I found out on the EML 510 for SOS CA was that we had the
"usual" design by iteration - around the XML - build a strawman - load
data - see where the gaps are - make changes - repeat.
That's less than ideal - in terms of knowing that you have the
requirements covered off.
Can we engage with the VIP folks to get that conceptual data model
done?
I think that would be a HUGE selling point for the states executives
- as they are much more likely to recognize that - than a bunch of schema
docs!!!
Thanks, DW
--------
Original Message --------
Subject: Re: [election-services] RE:
VIP/EML CONVERGENCE?
From: John Borras <>
Date:
Wed, July 30, 2008 12:22 pm
To: "Zelechoski, Peter"
<>, "David RR Webber
(XML)"
<>
Cc: EML TC
<>
Peter - you beat me to it.
David - I think you are getting ahead of us and
VIP. As Peter points out it is very unlikely that the States
hold geospatial info in their EMS systems, and all we are trying to
do for now is match what VIP want and that is to handle straight forward
extracts of relationship data from the States. What you are
proposing sounds great but is for the future I would suggest, maybe
EML v7. From my experience of election officials they are very
very slow to move to new ways of working so we need to be able to meet
their ancient ways of working for now and hope to educate them for the
future. Aaron Strauss made a very good point on the
recent telecon which you missed. He said one of their main
objectives of this phase of VIP was just to get the States to recognise
the need to use standards. Any debate about which standard
was for a future phase of their programme. So let's try and get
over this hurdle in the easiest and quickest way and then hope to
influence the future direction of VIP .....-)
Regards
John ( the UK Luddite!!)
M. +44 (0)7976 157745
Skype: gov3john
-----
Original Message ----
From: "Zelechoski, Peter"
<>
To: David RR Webber (XML)
<>
Cc: EML TC
<>; John Borras <>
Sent:
Wednesday, 30 July, 2008 5:02:37 PM
Subject: [election-services] RE:
VIP/EML CONVERGENCE?
David -
Most of the voter registration products seem to use
street segment files to define their areas. Each range of numbers
(e.g., 100-199) on a given street, and even or odd can be separated
as well, is a segment. These segments are then placed into a set
that defines a given precinct. That is the simple case and applies
to a large percentage but not 100% of the time. You can find
places where specific floors of a building are grouped,
etc.
These products don't use geospatial information, so
the likelihood that the jurisdictions will be able to provide that is
not good.
- Peter
From: David RR Webber (XML) [mailto:]
Sent: Wednesday, July 30, 2008 9:21 AM
To: John
Borras
Cc: EML TC
Subject: RE: [election-services]
Fw: VIP/EML CONVERGENCE?
John,
I think the one approach solves both. Frankly - the old
approach was needed because they did NOT have the means to solve it
easily - so it became a crazy morass of rules and amendments and notes
and changes.
It's the same problem in essence - where is my qualifying address
relative to the polling station and the geographic boundaries that
define it?
I'm not trying to compete with Google - instead - I'm looking to
use EML to empower their solutions (and all the other makers of mapping
solutions).
They all need the raw geographic information in a simple and
consistent way that is easy for the voting authorities to provide that's
compatible with the existing mapping engines and standards.
So whether you provide street address boundaries and intersections
- and / or geographic coordinates - the idea is the same - to spell out
what the physical area looks like.
By using geospatial and consistent street addressing together
(that's what its designed for!) - we can capture what that is in a
coherent way - and the mapping software can read that XML in and
visually show you it - so you know if you have it correct.
The last piece is then easy for the voter - provide their
own street address - software shows them where that is - what
precinct its inside (draws those lines as overlay on the map using
existing mapping API) - and directions to the polling location
address!
Thanks, DW
--------
Original Message --------
Subject: Re: [election-services] Fw:
VIP/EML CONVERGENCE?
From: John Borras <>
Date:
Wed, July 30, 2008 5:01 am
To: "David RR Webber (XML)"
<>
Cc: EML TC
<>
David
As I see it there are two distinct voter questions that VIP
is trying to handle. First, which is my polling station, and
second how do I get there.
The second one is clearly a Google maps type of scenario and we
shouldn't try and compete with that, just provide hooks to jump out to
those type of applications.
The first question is very different and is not in my
opinion a Google maps type of solution. The "which is" bit
depends on a number of factors and will/can be different for
different elections. This is where the business rules come
into play. So determining the voter's polling station depends on
which precinct/ward they are in for a given election and this is/can
be affected by population headcounts, local authority
boundaries, electoral jurisdictions etc. I don't see
mapping software handling all that complexity. All we need to be
able to do is handle a simple relationship table that links addresses
to precincts to poling stations for a given election. Let the
States admin folks use the business rules to work out the boundaries
etc and enter them into their EMS system, from which VIP can then
take an extract.
The EDXL solution seems to be fine to answer the question of
where is the nearest polling station to me but that may not be
the one I should use.
So as I said yesterday let's not get sucked too deeply into
geospatials etc.
Regards
John
M. +44 (0)7976 157745
Skype: gov3john
-----
Original Message ----
From: David RR Webber (XML)
<>
To: John Borras <>
Cc:
EML TC <>
Sent:
Tuesday, 29 July, 2008 8:23:10 PM
Subject: RE: [election-services]
Fw: VIP/EML CONVERGENCE?
John,
Yes - I agree a new EML 115 can capture the geographic
details of the area associated with the 110 polling place.
I'm seeing there is potentially an "easy" solution - use
almost the exact same method as OASIS EDXL is already. We can
"borrow" their schema imports of the CIQ and Geospatial XSDs.
They already have this. It would be a nice primer for us to
move to CIQ v3 next in EML V6.
Think we need to collect together the conceptual model first on
how this all would work (Paul - novel concept - do the information
model first!) - using street / GPS / map references to markout
the physical boundaries - store that in XML - but I'm seeing the means
to do this is probably already in the EDXL stuff.
Then ensure we have the right pieces from the VIP side too - and
the linkage to the 110.
Googles mapping engine should be able to place people's physical
address inside the boundary then - drawing it on the map and
pinpointing their house.
This is going to be a very cool application. Think the
states will have huge incentive to provide those EML 115 and EML 110's
to drive this with - and it will make their lives much easier -
instead of having to figure out all kinds of ugly addressing based
rules - let the mapping software do the work...
Thanks, DW
--------
Original Message --------
Subject: Re: [election-services] Fw:
VIP/EML CONVERGENCE?
From: John Borras <>
Date:
Tue, July 29, 2008 4:17 am
To: "David RR Webber (XML)"
<>
Cc: EML TC
<>
David
I'm not convinced we should handle geography specifically
within v6. I think it's out of scope for us. We can
leave hooks for users to insert their own preferred mapping tools,
eg Google maps, but let's not get sucked too deeply into this
aspect.
I agree we have within 110 most of what is needed for VIP
but the one bit we don't have is the link between a voter's home
address to their precinct and thus polling
station. The business rules that determine this are
usually within the election authorities' systems and all we've done
is handle the output from that which tells the voter on their
polling notification where to go to cast their vote. What VIP
want to do is handle the business rules as well so the third
parties can provide the searching facility direct to the
voter. So that's where I think we need the new message,
perhaps a 115.
Regards
John
M. +44 (0)7976 157745
Skype: gov3john
-----
Original Message ----
From: David RR Webber (XML)
<>
To: John Borras <>
Cc:
EML TC <>
Sent:
Monday, 28 July, 2008 2:31:30 PM
Subject: RE: [election-services]
Fw: VIP/EML CONVERGENCE?
John,
Good thoughts. I'm seeing for EML v6 we need to handle
geography! Mashups and Web 2.0 are upon us...
KML is Googles markup for maps, GPS and more. Most GPS
devices support KML.
You can do very cool things with it - such as this -
http://www.drrw.net/inside/travel/cycling-mashup.html
which obviously could be used to provide recommended route to
and from a polling station from nearby highway - etc.
Back to polling stations. Actually if we look at the
EML-110 election event - we have a chunk of this already.
Should give us a good model to follow to add in the additional
parts. I actually think this is closer than we realize.
Not sure how much new stuff we need - may only be one new
transaction that provides voter polling place linkages.
I worked on alot of things this weekend (including the EML
110!) - but still have some more testing and crosschecking to do
before everything is ready to share the full analysis with the
group.
Thanks, DW
--------
Original Message --------
Subject: Re: [election-services] Fw:
VIP/EML CONVERGENCE?
From: John Borras <>
Date:
Mon, July 28, 2008 5:43 am
To: EML TC
<>
Thanks for all the very useful contributions. Looks
like we will need to have a very flexible new suite of
messages to accommodate the address - precinct- polling station,
including opening days/hours, set of relationships, and their
linkages to contests. Not sure I've seen this
complexity in the VIP stuff so far but maybe as they roll it out
they will come across the need for it.
David - two questions on your note
below. First what's KML? And secondly the VIP
requirement is primarily about which polling station do I have
to use not how do I get there. So EDXL HAVE might not
be appropriate if it's focus is just on giving directions?
So where does all this leave us and how do we take it
forward? Well in my opinion we need to review David's
address handling facility first to see if that meets the VIP
needs. Secondly we then need to build the new messages to
handle the geography elements for polling station
allocations. And finally develop any further EML schema
localisations needed for the remainder of the VIP
requirement. Having got that set together we can then ask
them to validate it before working out a cross-over strategy with
them.
Agreement or alternative views would be appreciated plus
views on whether we need to have a TC telecon to discuss this
further.
Regards
John
M. +44 (0)7976 157745
Skype: gov3john
-----
Original Message ----
From: David RR Webber (XML)
<>
To: Richard J Cardone <>
Cc:
EML TC <>
Sent:
Friday, 25 July, 2008 9:20:28 PM
Subject: RE:
[election-services] Fw: VIP/EML CONVERGENCE?
Richard,
OK - thanks for reminding me one of the core values here for
VIP - pointing people at the right polling place!
So -thinking about this - its not a pollbook type of function
- its a public information one.
What EML is setup to carry is the ballots, candidates
and polling place information.
So this is an additional function associated with polling
place - which relates to address boundaries.
And then now we're seeing another - which is early balloting
and those mechanisms. I'd add to that absentee
ballots.
So there's potentially two new types of EML supplemental
transactions. For the address boundaries I'd add geospatial
and support for KML. Fortunately this has already been done
for us using CIQ!!!
The new OASIS EDXL HAVE schema is doing exactly this for
hospitals and emergency management. In that case its "how do
I get to the right hospital?". Substitute polling station
for hospital and we can borrow all that part of their XML!
Then for the "means to vote" - I don;t think we have anything
specific right now. However in both instances - we can
re-use the eml-common lexicon of xml parts - to assemble these
pieces from is my sense - and hence tie them neatly into the "EML
family".
Thanks,
DW
-------------------------------------------------------------------------------------------------------
Rich -
I would agree that there are locales where
that happens -- the polling locations have set hours/days but an
individual would still be in a precinct (the precinct determines
what contests are contained on the individual's
ballot).
In Texas there are places where early voting
is done at regional locations and anyone can go to any
location. They are still assigned to a precinct, it is just
that all precincts can go to all early voting locations. On
election day the polling locations become localized and
individuals are routed to their local polling place that handles
one precinct (or a small number of precincts).
Polling locations actually change frequently
(a church or social hall is under repair and they move to a
different facility for the current election). Precincts
usually change only when redistricting or such takes
place.
- Peter
-------- Original Message --------
Subject: RE:
[election-services] Fw: VIP/EML CONVERGENCE?
From: Richard J
Cardone <>
Date:
Fri, July 25, 2008 2:30 pm
To: "EML TC"
<>
Peter and John,
There is the case where polling places can
change over time in an election. For example, voters may be
directed to centralized polling places during early voting. At
some point, early voting ends and election day--the final day of
voting--arrives. On election day, voters may be directed to
their neighborhood polling places, which are different than the
centralized polling places.
Rich
---------------------------------------------------------------------
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
Not happy with your email address?
Get
the one you really want - millions of new email addresses available now at
Yahoo!
---------------------------------------------------------------------
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
Not happy with your email address?
Get
the one you really want - millions of new email addresses available now at
Yahoo!
Not happy with your email address?
Get
the one you really want - millions of new email addresses available now at
Yahoo!
---------------------------------------------------------------------
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
Not happy with your email address?
Get
the one you really want - millions of new email addresses available now at
Yahoo!
---------------------------------------------------------------------
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
Send instant messages to your online friends http://uk.messenger.yahoo.com/
Send instant messages to your online friends http://uk.messenger.yahoo.com
---------------------------------------------------------------------
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
Send instant messages to your online friends
http://uk.messenger.yahoo.com
Next in thread →
Next in month →