OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

election-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [election-services] The Future of EML

It's hard to predict.  We may put all the effort there - and they ask for something else entirely!
I agree with the need - it has become excessively difficult to discern this stuff just looking at the schemas and the structure diagrams themselves.
However - I don't see value in beating ourselves up right now - when as we move forward - we can have more time to distill this out - as we know the ISO process is not rapid!
The important thing is that you have alerted everyone to the needs - now we must address it with whatever resources we can draw from.  Perhaps the EU and NIST jointly can step in to develop a data model, or share what they have already?
Thanks, DW

"The way to be is to do" - Confucius (551-472 B.C.)

-------- Original Message --------
Subject: RE: [election-services] The Future of EML
From: "Paul Spencer" <paul.spencer@boynings.co.uk>
Date: Thu, April 12, 2007 6:50 am
To: "John Borras" <johnaborras@yahoo.co.uk>, "eml"

I think we are basically in agreement that this work should be done sometime. My concern is that it becomes harder to make structural changes after the ISO process. My experience of ISO standards has also been that they generally start in a syntax-independent style, then add the XML on top. This would require the data model.
Whilst we don't want to delay the ISO process, I wonder if it will take longer if our work is not in that form.
-----Original Message-----
From: John Borras [mailto:johnaborras@yahoo.co.uk]
Sent: 12 April 2007 09:59
To: Paul Spencer; eml
Subject: Re: [election-services] The Future of EML

It was probably inevitable that we have arrived at a version of EML that is not optimal as the requirement continues to evolve and experience gained as we come to use the schemas.  Clearly if we knew back in 2001 what we know now we would have ended up with a better specification. However let's not lose sight of the fact that what we have is far superior to anything else around.  I don't get the sense that any of it is wrong, just that it could be better.  I don't share your concerns about going into ISO with this version.  I don't think we should fear other experts who might criticise  it, we have most of the global e-voting expertise within the TC and the Council of Europe working group, and that body of opinion gives us a considerable advantage.
We have adopted the process of modifying the schemas periodically in the light of experience and if what you say about 120 and others being superfluous we should add that to the next update cycle, when we can also feed in any further changes resulting from the next UK and Belgium pilots.  We can correct any documentation problems in the current Public Review round so perhaps you and David can post comments to that effect so there is a formal record which we can address at the end of the review cycle.
We have discussed your suggestion before about producing a data model and clearly we are not going to get anybody to fund that work.  However I am prepared to put some personal time into this so perhaps we could meet up at your convenience to scope out what needs to be done etc.  If the TC are content with our plans we can include that work into the next version of EML.
M. +44 (0)7976 157745

----- Original Message ----
From: Paul Spencer <paul.spencer@boynings.co.uk>
To: eml <election-services@lists.oasis-open.org>
Sent: Wednesday, 11 April, 2007 1:30:41 PM
Subject: [election-services] The Future of EML

In my recent work involving EML, it has been clear that the clarity and
consistency of the specification are suffering badly from the effects of its
continued evolution. Some years ago, I suggested building a proper data
model, but this was turned down on cost grounds.

Typical of the issues I am now finding is that the 330, which was originally
intended to supply a list of electors for the purpose of voting,  has
evolved to cover most areas where such a list is required. For example, in
the UK, it is being used to provide a list of electors to credit reference
agencies. This means it is duplicating the 120 message, and I am being asked
which should be used. If there is this confusion, it will lead to
inconsistent implementations. Now I am being asked for similar features in
the 230. It seems logical to remove the 120 and expand the 230, 330 and 630
to cover its functions.

This is just one example. I believe that a thorough review of the schemas,
including the development of a data model, would help clarify many points
and help with consistency of implementation. Since the ISO process is not
one to be taken lightly, I would like to see it done before submission. I
currently worry about the feedback we will get if other experts look at the
current version in detail.

Why can't we just get on and do this work? Because, in spite of the presence
on the TC of several large companies working in the multi-billion dollar
voting industry, most of the technical work is being left to two individuals
who receive no payment. Is it not time for some of the big companies either
to allow some staff to work on this or put up some money so that the current
volunteers can do a decent job?

We should be able to get EML up to the standards of UBL and other
specifications that have had significant resource thrown at them. If not, it
reflects badly on the industry and will end up costing people more as
interoperability becomes harder to manage.


Paul Spencer
Boynings Consulting Ltd

Yahoo! Mail is the world's favourite email. Don't settle for less, sign up for your free account today.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]