RE: [election-services] Re: Enhancing Referendum items handling

[John Borras <johnaborras@yahoo.co.uk>]

David

 

Thanks that sounds a much better approach.  Let's see what others think.

 

John

"David RR Webber (XML)" <david@drrw.info> wrote:

John,

 

OK - I just spent an interesting few hours investigating all this. 

 

Paul is right - we need that reference information model!!!

 

What I determined is this.

 

1) The 600 series handles proposals / options / referendum items

 

2) The proposal / referendum model is slightly odd - notice that the linkage - name / description (lang) / referendum item ID - is a one to many to many relationship. 

 

3) There are gaps in this - apart from the obvious fact you really want a 1-to-1 for description (referendum item ID) - the most obvious is the lack of ability to associate a response to an item/description - such as yes/no/abstain ... etc.

 

4) There is no way currently to link from 410, 510, 520 to proposal item in 600 (should be via name key token ) except via referendum item ID - but we already know from 3) that this may point to an indeterminate reference.

 

So - in order to resolve this - enable the re-use of the existing EML 600 stuff - and support referendum items cleanly.

 

1) Add a second structure varient to 600 Proposal series that is 1-to-1 for description / item ID

2) In that second structure varient support the yes/no/abstain response needs

3) Tweak the Candidate structure to add option of new Proposal item structure from 600

 

This actually appears to work very nicely with only minimal changes to the EML commons xsd - everything else then inherits those new capabilities.  It means you can now design a 410 that includes proposal items from the 600 directly (whereas before you could not).  Similarly the 510 and 520 counting and reporting now include the proposal items directly too.

 

And it leaves the current 600 processing untouched - so that however people were using it before is all there.  Ditto the Candidate handling details in the existing schemas. 

I see now why you earlier said it was essential to provide the 600 series - instead of overloading Candidate.  What I see I have done here is closed the last piece of the puzzle and allowed the option to reference the 600 definitions directly from whereever "Candidate" exists today.

 

OK - so summarizing this at the XSD level - what I did was two things:

 

A) Extend the 600 Proposal structure to add an alternate referendum style layout

 

B) In Candidate structure definition - add optional ability to use a 600 Proposal item reference model, instead of the 230 Candidate model.

 

C) All these changes actually happen in just two places in the EML commons - and then are inherited via the includes.

 

Hope this makes sense to everyone - I will post these draft schema changes to the list so everyone can review them. 

 

Thanks, DW

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

-------- Original Message --------
Subject: [election-services] Re: Enhancing Referendum items handling
From: John Borras <johnaborras@yahoo.co.uk>
Date: Tue, May 22, 2007 10:08 am
To: "David RR Webber (XML)" <david@drrw.info>
Cc: 'EML TC' <election-services@lists.oasis-open.org>

David

 

We originally used Candidate to refer to either an election or a referendum.  That got very complicated when we got the detailed requirement from the Swiss so we split out the 600 series of schemas and introduced the ProposalStructure in EML Core to specifically handle referendums thus leaving Candidate to relate solely to elections.  I'd be loathed to go back to including referendums in with Candidates as I think you are suggesting.  If things are missing or wrong then we should be looking to use/enhance the ProposalStructure and/or the 600 series in my opinion.  Do you see any problems with that approach?

 

John

 

 

 

"David RR Webber (XML)" <david@drrw.info> wrote:

Team,

 

I've looked at the options here - and pro-offer the below as a solid way forward with minimum impact on what we have already.

 

Plus - I believe this will really make implementers lives much easier!

 

If we concur then I will post this as a comment to the public review.

 

Thanks, DW

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

=======================================

 

Referendum Items Handling

 

We have the referendum id item in the 510, 440 and 410 - but the ID and details are missing from the 230 and the 520.

 

This means it is not possible to declare the referendum items other than in the 410 itself, and also not possible to easily equate groups of referendum items that are selections and report results in the 520 and 510.

 

To solve this I'm proposing to include into the CandidateStructure and CandidateIdentifierStructure the ability to define and reference referendum items.

 

This would mean that a candidate item could then be a referendum question.  I believe this is the design intent - but without them also appearing in the 230 - there is no mechanism to centrally define them individually and as a set of grouped items.

 

Therefore here is what I believe the referendum item should look like

 

<ReferendumItem ReferendumOptionIdentifier="value99" ReferendumItemGroup="value999" language="US-en">
 <ReferendumText>Required text goes here</ReferendumText>
 <SelectionText>Accept</SelectionText>
</ReferendumItem>

 

This would allow you to create referendum items as currently candidates are - and then enter multiple ones where necessary for related items such as accept/reject/abstain as a group with group identifier.

 

Referendum will inherit all the same benefits as candidate - such as endorsements, sponsors, affliation, etc.

 

The logic in the 440 and 510 will then remain unchanged - except in the 520 you can now report the correct details for accept/reject/abstain totals accordingly - and now - because the candidatestructure actually will now have the referendum item details - you will be able to store that text there.

---

Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now.

---

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