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