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

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

Paul,

Agreed.  One thing that CAM brings on the validation front is
ability to handle context variables - so you could vary the
inclusion or exclusion of fields depending on the type
of ballot, and the locale.  Admittedly - this is probably
a lessor need - given that there's not huge differences
in your audit content today.  I'd say its a classic 80:20 rule,
where that extra 20% maybe something CAM can give
in addition to the 80% that Schematron does already
today.

Your example of database checks is interesting though,
because you can do those levels in CAM, or things like
special hash value checks by calls to external routines.
You would have to be careful to do this only within
one layer (such as during the post-ballot verification)
as you cautioned.  But the attraction of being able
to do this all with open source and driven by open
XML scripts could be compelling.

Another interesting use - when you consider paper ballots -
is the ability to associate rendering post-validation - so
you could have explicit CAM templates that did French,
Flemish, Dutch, English, etc where multi-lingual handling
is important - and route those to a ballot printer.

Election officials could then configure a ballot just by
issuing XML driver scripts with the ballot options
in them.  This is obviously highly attractive as the
software installed on the DRE machines does not have
to be touched and can remain sealed.

DW

----- Original Message ----- 
From: "Paul Spencer" <paul.spencer@boynings.co.uk>
To: "David Webber (XML)" <david@drrw.info>; <charbel.aoun@accenture.com>;
<sibain@tendotzero.com>
Cc: <election-services@lists.oasis-open.org>
Sent: Wednesday, February 23, 2005 11:36 AM
Subject: RE: [election-services] Defining a trusted voting process - one
disabilities concern


> David,
>
> I am not saying that CAM could not do the job, just that we chose a
> mechanism before CAM existed and it has served its purpose up to now. We
> would therefore need a compelling reason to change. Schematron wouldn't
> work, for instance, if we wanted database access as part of the
validation.
> Although I rather suspect that any scenario requiring database access
(e.g.
> "has this person already voted through another channel?") would break some
> of your security concerns.
>
> Regards
>
> Paul
>
> > -----Original Message-----
> > From: David Webber (XML) [mailto:david@drrw.info]
> > Sent: 23 February 2005 16:31
> > To: Paul Spencer; charbel.aoun@accenture.com; sibain@tendotzero.com
> > Cc: election-services@lists.oasis-open.org
> > Subject: Re: [election-services] Defining a trusted voting process - one
> > disabilities concern
> >
> >
> > Paul,
> >
> > I'm not sure Schematron gives you quite such flexiblity with
> > defining structures contextually - but Schematron would be my second
> > choice -
> > particularly to cover off crossfield validations that XSD cannot do
> > as a first need.
> >
> > Anyway - good that you've already adopted the approach - that's
> > the main thing - we can argue tools and means to do-what-where
> > and enjoy all that based on peoples needs...
> >
> > Cheers, DW
> >
> > ----- Original Message -----
> > From: "Paul Spencer" <paul.spencer@boynings.co.uk>
> > To: "David Webber (XML)" <david@drrw.info>;
<charbel.aoun@accenture.com>;
> > <sibain@tendotzero.com>
> > Cc: <election-services@lists.oasis-open.org>
> > Sent: Wednesday, February 23, 2005 11:14 AM
> > Subject: RE: [election-services] Defining a trusted voting process - one
> > disabilities concern
> >
> >
> > > That's what we are using Schematron for.
> > >
> > > Regards
> > >
> > > Paul
> > >
> > > > -----Original Message-----
> > > > From: David Webber (XML) [mailto:david@drrw.info]
> > > > Sent: 23 February 2005 15:34
> > > > To: charbel.aoun@accenture.com; paul.spencer@boynings.co.uk;
> > > > sibain@tendotzero.com
> > > > Cc: election-services@lists.oasis-open.org
> > > > Subject: Re: [election-services] Defining a trusted voting
> > process - one
> > > > disabilities concern
> > > >
> > > >
> > > > Charbel,
> > > >
> > > > Everyone seems to have angst with this.  I'm just watching UBL-dev
> > > > go thru the same thrash (again).
> > > >
> > > > When it comes to the schemas themselves - you just need a
> > > > formal approach and method to be able to manage this.
> > > >
> > > > OAGi have been doing this with their BODs with success for
> > > > years now by having a specific <user_extensions_area> in
> > > > each of the schemas.  That is only part of the solution however.
> > > > They still get into trouble on codelists and localization issues.
> > > >
> > > > The bottom line is that schema is ill-equipped to support
> > > > systematic variences and business contextual needs.  It
> > > > just ain't in the design envelope.  Sure there are mechanisms
> > > > that allow you to re-define stuff - but they hide and
> > > > obfuscate what is going instead of making it open.
> > > >
> > > > I've been advocating how the OASIS CAM template
> > > > approach can augment your base schemas and capture all
> > > > this local usage pattern detail.  That's what its designed to
> > > > do - and using XSD and CAM together definately gets
> > > > you out from under this rock.  So you publish your formal
> > > > schema - and then sets of CAM templates for specific
> > > > localization and contextual use patterns.
> > > >
> > > > This is quite simply how the world works - and having
> > > > the means to manage it is key.  Of course you also
> > > > publish enhancements to the base schema too - as
> > > > you migrate local discoveries over into the main base.
> > > >
> > > > Anyway - that's my take on this - otherwise you get
> > > > too tightly wound around the pole and it impacts
> > > > your ability to bring in communities into your base
> > > > and evolve to broader use of your specifications.
> > > > That was the older EDI world - and we are trying
> > > > to do better!
> > > >
> > > > Cheers, DW
> > > >
> > > > ----- Original Message -----
> > > > From: <charbel.aoun@accenture.com>
> > > > To: <paul.spencer@boynings.co.uk>; <sibain@tendotzero.com>
> > > > Cc: <election-services@lists.oasis-open.org>
> > > > Sent: Wednesday, February 23, 2005 10:20 AM
> > > > Subject: RE: [election-services] Defining a trusted voting
> > process - one
> > > > disabilities concern
> > > >
> > > >
> > > > Are you coordinating this approach with the ODPM (in the UK
context)?
> > > > In 2003 when a consortium proposed "Enhanced EML" they were almost
> > > > disqualified. At the time EML was still a theory and those who
brought
> > > > changes to EML where penalized. Now you indicate that
> > variation would be
> > > > acceptable if necessary and this I know for a fact (not only based
on
> > > > the past but current discussions) contradict what is in mind.
> > > >
> > > > 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: Paul Spencer [mailto:paul.spencer@boynings.co.uk]
> > > > Sent: 21 February 2005 19:21
> > > > To: sibain@tendotzero.com
> > > > Cc: eml
> > > > Subject: RE: [election-services] Defining a trusted voting
> > process - one
> > > > disabilities concern
> > > >
> > > >
> > > > I half agree. Part of the reason for the extensibility is to allow
> > > > national variations. There are always some things that will
> > change on a
> > > > national basis. These should not need to go through the TC before
use.
> > > > If they are sufficiently common to become part of EML, then
> > they should.
> > > > Of course, people may want to consult the TC on whether something is
a
> > > > national variation or should be part of EML itself.
> > > >
> > > > Regards
> > > >
> > > > Paul
> > > >
> > > > > -----Original Message-----
> > > > > From: Simon Bain [mailto:sibain@tendotzero.com]
> > > > > Sent: 21 February 2005 16:28
> > > > > To: Paul Spencer
> > > > > Cc: eml
> > > > > Subject: RE: [election-services] Defining a trusted voting
process -
> > > > > one disabilities concern
> > > > >
> > > > >
> > > > > Ithas certain extensibility built in yes.
> > > > > I am not sure how far this goes as I have not gone through
> > it totally.
> > > > >
> > > > > However the sub schemas should also come from the TC so
> > that they are
> > > > > taken as part of the standard. By creating a schema / dtd
> > in this way
> > > > > you will then be able to keep hold of the standard, whilst
allowing
> > > > > people to make / suggest changes without the need to worry about
the
> > > > > core schema / dtd having to be changed for everyone.
> > > > >
> > > > > Cheers
> > > > > Simon
> > > > > --
> > > > > Simon Bain
> > > > > TENdotZERO
> > > > > ----------
> > > > > Tel:    0845 056 3377
> > > > >         44 1234 359090
> > > > > Mobile: 44 (0)7793 769 846
> > > > >
> > > > > <quote who="Paul Spencer">
> > > > > > I realised after posting an earlier reply that I should have
> > > > > mentioned the
> > > > > > extensibility of EML. I think it does what you are
> > suggesting here.
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Paul
> > > > > >
> > > > > >> -----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/l
> > > eave
> > > >> _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/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.
>
>
>