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] 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.
>
>
>
>
>
>




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