Re: [election-services] Defining a trusted voting process - one disabilities concern

["David Webber \(XML\)" <david@drrw.info>]

Charbel,

Your points reinforce the need to continually refine our trusted process
model.

This to me is the lynchpin that guides implementers - and also determines
interoperability and conformance testing.

Thanks, DW

----- Original Message ----- 
From: <charbel.aoun@accenture.com>
To: <sibain@tendotzero.com>; <paul.spencer@boynings.co.uk>
Cc: <election-services@lists.oasis-open.org>
Sent: Monday, February 21, 2005 7:58 AM
Subject: RE: [election-services] Defining a trusted voting process - one
disabilities concern


In a natural evolution of EML we should expect and I believe it is
normal to have an evolving EML. Apart from the few suppliers that
implemented EML in 2003 there is no previous experience or real
implementation we can refer to. With that in mind and with the fact that
EML is still changing (though less an less) we can not talk "yet" about
stability. Stability will be achieved once we have across the board an
EML compliance and intergation among the vendors. After which we can
talk stability. Till than expect that while the legislation may be
changing to accommodate modernization and while the users are
discovering what they need and can do from this new electronic format,
EML in the meantime will keep on changing.
For those who played with EML in 2003 and I am one of them, experience
showed us what is agreed on in this committee does not necessarily aply
on the ground or provide a practical solution.
Cheers

Charbel Aoun
Accenture eDemocracy Services
Director of Operations and Technology - International
105 Ladbroke Grove
London, W11 1PG
United Kingdom
M +44 794 925 2143
T  +44 207 616 8414
Octel 43/ 40363
email: charbel.aoun@accenture.com



-----Original Message-----
From: Simon Bain [mailto:sibain@tendotzero.com]
Sent: 21 February 2005 09:14
To: Paul Spencer
Cc: eml
Subject: RE: [election-services] Defining a trusted voting process - one
disabilities concern


Hi.

I am one of those which does implement EML. I am also of the view and
was very much of this oppinion during the development of the code in the
2003 local elections that standards should not change continually, as
this gives people reasons to not use it and/or continual software
updates which customers then get annoyed with.

However all standards should be extensible. This does 2 things
1) Allows users to input their own tags. (Can be dangerous and not allow
for open cross border use)
2) Allows the standards body to define sub schemas which then can be
taken into the main schema if required by the using authority.

What a standard should not become is static, which I know you are not
suggesting. A standard should also not be closed to new thoughts and
suggestions, even after it has been approved and announced. Again
something I know that you are not suggesting.


So in my oppinion there should be a stable almost non changing standard
with enough extensibility placed in it to allow other smaller more
specific schemas to be defined by the standards body and then adopted by
users. These would plug n to the main schema, making it extensible and
controllable.

This would then allow for the additions of items after due consideration
and thought to be added in a sub schema. For ideas put over not only by
David but also by others as they start to use the schema. The standard
still remains under the control of the standards body but allows for a
much easier adoption and sharing ability, and also allow it to grow and
prosper. After all in 98 at the SGML conference in Paris this is what
most users and vendors were screaming for in the new XML syntax. Not to
have a fixed DTD one which was not extensible and one that could not
move with the rest of the World.

Cheers from a very cold Bedford
Simon
-- 
Simon Bain
TENdotZERO
----------
Tel:    0845 056 3377
        44 1234 359090
Mobile: 44 (0)7793 769 846

<quote who="Paul Spencer">
> Simon,
>
> The basic point is that people are currently implementing EML, and
> won't do so if the specification is changing continually. So it is
> more that we should consider changes as part of an improvement cycle
> over some specified
> time period. If David is looking at defining and agreeing an electoral
> process, that will take some time (perhaps 6-12 months within OASIS,
but
> considerably longer to get any nation to agree to adopt it) and EML
could
> then be adjusted to fit.
>
> At least, that is my understanding and opinion. Perhaps John Borras
> has a different view.
>
> Regards
>
> Paul
>
>> -----Original Message-----
>> From: Simon Bain [mailto:sibain@tendotzero.com]
>> Sent: 20 February 2005 07:57
>> To: Paul Spencer
>> Cc: "David Webber " <david@drrw.info>,
>> election-services@lists.oasis-open.org"@tendotzero.com
>> Subject: RE: [election-services] Defining a trusted voting process -
>> one disabilities concern
>>
>>
>> Paul hi.
>>
>> What do you mean by "stability".
>> Do you mean that you do not want any updates to the EML spec or do
>> you mean that you mean that any future updates should be pllaced on
>> hold for a given period of time?
>>
>> All the best
>> Simon
>> --
>> Simon Bain
>> TENdotZERO
>> ----------
>> Tel:    0845 056 3377
>>         44 1234 359090
>> Mobile: 44 (0)7793 769 846
>>
>> <quote who="Paul Spencer">
>> > v4 has been released. We are looking for some stability at the
>> moment, but
>> > that does not mean that we don't want to continue to move forwards.
>> John
>> > Borras chairs the TC, and this would be a subject for the meeting
>> > he
>> is
>> > suggesting.
>> >
>> > Regards
>> >
>> > Paul
>> >
>> >> -----Original Message-----
>> >> From: David Webber (XML) [mailto:david@drrw.info]
>> >> Sent: 19 February 2005 16:31
>> >> To: Paul Spencer; election-services@lists.oasis-open.org
>> >> Subject: Re: [election-services] Defining a trusted voting
>> process - one
>> >> disabilities concern
>> >>
>> >>
>> >> Paul,
>> >>
>> >> Just reviewed the EML docs and schemas and sent some public
>> >> comments to the OASIS comments list.  Some of this can be
>> >> addressed now - but other matters are going to need more work.
>> >> Are we on a timetable to release EML 4.0 here - or do we have
>> >> another release cycle here to use up?  Otherwise a 4.5 release to
>> >> catch these other matters clearly is another option.
>> >>
>> >> Thanks, DW
>> >>
>> >> > David,
>> >> >
>> >> > Have you read the EML documents? This is a start on a viable
>> process.
>> >> At
>> >> the
>> >> > time, we felt we needed a reference process to help us define
>> >> the schemas.
>> >> > We also felt that this process would vary a lot
>> >> internationally. However,
>> >> > there are certain key points (mainly to do with trust) that can
>> >> > be standardised on an international basis.
>> >> >
>> >> > I would love to see the OASIS E&VSTC get involved in this, but
>> >> I wonder if
>> >> > OASIS is the right place for this. On the other hand, it could
>> >> be the only
>> >> > place that would take a truly international (rather than
>> >> US-centric) view.
>> >> > Also, from a personal view, having spent a considerable time
>> helping
>> >> get
>> >> EML
>> >> > to the stage it is, I would like any new initiative to use it.
>> >> >
>> >>
>> >>
>> >>
>> >> To unsubscribe from this mailing list (and be removed from the
>> >> roster of the OASIS TC), go to
>> >> http://www.oasis-open.org/apps/org/workgroup/election-services/mem
>> > bers/leave_workgroup.php.
>> >
>> >
>> > To unsubscribe from this mailing list (and be removed from the
>> > roster
>> of
>> > the OASIS TC), go to
>> >
> http://www.oasis-open.org/apps/org/workgroup/election-services/members
> /leave
> _workgroup.php.
>>
>


To unsubscribe from this mailing list (and be removed from the roster of
the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/election-services/members/l
eave_workgroup.php.



This message is for the designated recipient only and may contain
privileged, proprietary, or otherwise private information.  If you have
received it in error, please notify the sender immediately and delete the
original.  Any other use of the email by you is prohibited.

To unsubscribe from this mailing list (and be removed from the roster of the
OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/election-services/members/leave_workgroup.php.