RE: Enhancing Referendum items handling

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

John,

 

Let me review the 600 series and see what is happening there and provide feedback,

 

Thanks, DW

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

-------- Original Message --------
Subject: 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.