David,
Your thought is correct. Sorry if I wasn’t clear.
Paul
From: David RR Webber (XML)
[mailto:david@drrw.info]
Sent: 30 March 2009 20:38
To: John Borras
Cc: eml
Subject: RE: [election-services] Deprecating EML 120 for EML 330 in V6
I think Paul was saying we keep the 230 - but may need to add
pieces there to cover off 120 functionality too.
Least ways that was how I read it.
Obviously we want to always simplify and rationalize as we can -
but that's harder to do of course and takes more time to accomplish...
-------- Original Message
--------
Subject: RE: [election-services] Deprecating EML 120 for EML 330 in V6
From: "John Borras" <john@pensive.eu>
Date: Mon, March 30, 2009 12:22 pm
To: "David RR Webber (XML)" <david@drrw.info>
Cc: "eml " <election-services@lists.oasis-open.org>
Just one (last) thought on all this. We need to be aware
of some criticisms in the past that some of the schemas are too large to
process, so merging 330, 120 and 230 might just add to that criticism unless we
can rationalise along the way.
Apart from the size issue I’m not sure it’s good design to have
a multi-purpose schema as 330 will turn out to be – what’s your view on that
aspect?
From: David
RR Webber (XML) [mailto:david@drrw.info]
Sent: 30 March 2009 17:08
To: Paul Spencer
Cc: 'eml '; John Borras; 'Zelechoski,Peter'
Subject: RE: [election-services] Deprecating EML 120 for EML 330 in V6
OK this is a huge help - now I understand the use cases better.
I'll look at where that stuff on the dSig came from - that
may just be in the old CIQ schema imports.
Also - I can run the 230 dictionary off - and merge with 330 - and
then do compare again - see what that shows. Since thats all automated
its quick to do.
No rush here in getting to an immediate solution. We can
continue to analyze this and review documentation over next few weeks - and
that should save time once you can spend time to desk check the specific
details.
I have other stuff I need to work on for v6 in the meantime!
-------- Original Message --------
Subject: RE: [election-services] Deprecating EML 120 for EML 330 in V6
From: "Paul Spencer" <paul.spencer@boynings.co.uk>
Date: Mon, March 30, 2009 11:42 am
To: "'David RR Webber (XML)'" <david@drrw.info>,
"'Zelechoski,Peter'"
<pzelechoski@essvote.com>
Cc: "'eml '" <election-services@lists.oasis-open.org>,
"'John Borras'"
<john@pensive.eu>
http://www.w3.org/TR/REC-html40">
The trigger for looking at this was that the CORE project in the
UK was using the 330 basically to transfer information between databases. There
are several exports from electoral registration systems that are basically lists
of electors for different purposes, filtered in different ways. Logically, you
could argue that the 330 if right is the data is being printed, but the 120 if
it is going into another database. Since you don’t know the use of the data
when sending it, there must be a big overlap. And what about data being
transferred from an electoral register to an election management system? The
initial thought was that this was a 330 again. The 120 was a late addition
intended for transferring electors between one electoral register and another.
The overlap just seems too great.
Looking at the EML v5 120, it is not just the 330 that would
change to replace it, the 230 would as well.
Looking at the v5 schemas, I also don’t see any digital
signature stuff. Where is that from? Similarly with the xNAL stuff – the Voter
name and address are in both schemas, so both should have the xNAL elements
included.
I am afraid I am still working a 7 day week out here in Abu
Dhabi, so I am having difficulty looking at this in detail. But I think the
schema diagrams are a more useful source for comparison than the spreadsheets
in their current form.
If it’s all too difficult, we can always leave it for another
time. I had always seen this going with the development of a better data model.
From: David
RR Webber (XML) [mailto:david@drrw.info]
Sent: 30 March 2009 01:58
To: Zelechoski,Peter
Cc: eml ; John Borras; paul.spencer@boynings.co.uk
Subject: RE: [election-services] Deprecating EML 120 for EML 330 in V6
Notice there is nothing to stop existing users of 120 continuing
to do so. However if we find that there are better ways of doing this all
in 330, and that certain aspects of the 120 have become redundant - then it
behoves to state that and not perpetuate less than optimal practices going
forward with v6. After the whole point of v6 is to makes things smarter,
better, easier...
--------
Original Message --------
Subject: RE: [election-services] Deprecating EML 120 for EML 330 in V6
From: "Zelechoski, Peter" <pzelechoski@essvote.com>
Date: Sun, March 29, 2009 1:17 pm
To: "John Borras" <john@pensive.eu>, "David RR Webber
(XML)"
<david@drrw.info>, <paul.spencer@boynings.co.uk>
Cc: "eml " <election-services@lists.oasis-open.org>
John, although I agree with David's desire for a sanity check,
I can support your supposition from my experience. I don't have
any practical use, only samples that I have played with. So, I can't give
you an indication of how true users will react if we change it.
From: John Borras [mailto:john@pensive.eu]
Sent: 2009-03-29 10:49 AM
To: David RR Webber (XML); paul.spencer@boynings.co.uk
Cc: eml
Subject: RE: [election-services] Deprecating EML 120 for EML 330 in V6
OK I understand and agree your logic, but I doubt apart from
Paul who raised the issue of removing the 120 that we have much if any
experience of using it.
Paul – Is there anything in the 120 that we can remove in this
transition?
From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: 29 March 2009 16:37
To: John Borras
Cc: eml
Subject: RE: [election-services] Deprecating EML 120 for EML 330 in V6
Was hoping for input from the team first. People who are
using 120 and 330 and how they see this needs to be aligned. Things
change so we need a sanity check - on whether these should be
continued - I don't just want to blindly put things in without
understanding the role and purpose they then fulfil in the 330. If we can
simplify and rationalize then we should take this opportunity to do that.
--------
Original Message --------
Subject: RE: [election-services] Deprecating EML 120 for EML 330 in V6
From: "John Borras" <john@pensive.eu>
Date: Sun, March 29, 2009 10:28 am
To: "David RR Webber (XML)" <david@drrw.info>
Cc: "eml " <election-services@lists.oasis-open.org>
The simple answer surely has to be, if there’s stuff in 120
that’s not in 330 then it needs to be added to the later before we can delete
the 120. We cannot afford to lose any data in this exercise as we
established way back that the 120 was a necessary process that had to be part
of EML. So unless I’m misunderstanding your question all the orange stuff
has to be added.
I assume all the orange stuff about addresses is the result of your
CIQ import, and that needs to be in 330.
I don’t see what your query is about the signature stuff – can
you be more explicit about which items are confusing you.
If you think we need a quick telecon to go through this, and
maybe other bits of V6, then let’s set that up.
Thanks for your efforts so far.
From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: 27 March 2009 19:18
To: eml
Subject: [election-services] Deprecating EML 120 for EML 330 in V6
Attached is a spreadsheet I autogenerated using CAM - comparing
the components of the 120 to the 330.
I have labelled those items in 120 that appear to not
be in the 330 in orange.
Can we sanity check these please? Seems like the signature
stuff may be something we need to resolve?
Is there anything else? If you want to provide feedback -
probably easiest is to edit the spreadsheet - and mark those items we need to
add to the 330 accordingly (green).
I've also included the EML 330 dictionary of the core components
CCTS - so you can further analysis what may already be in the 330 that can be
applied for the 120.
Once we have this all resolved - then I plan to remove the 120
from the V6.
---------------------------------------------------------------------
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
|