RE: [election-services-comment] more on 630 OptionsList

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

John,

 

This messages structure thing really sounds like some web service or other software device specific to Scytl. 

 

Obviously implementers are free to use whatever in memory representations they wish for their own software - and internal communications mechanisms - and derive those from the EML as needed (personally I feel plain-text message exchanges of ballot related information between software components in a voting system is a significant design flaw!).

 

The idea with Proposal data model is not to create factorial combinations for language permutations!  

 

Obviously if the voter is using one language - all questions and answers should be in that language!!  Therefore with 3 languages - you will only have 3 sets of texts.

 

Usually one language is set as the reference language - and then all responses can be mapped back and recorded as that.  Recording peoples responses in language specific text - again I'd label that a serious design flaw - likely to expose votes from one particular background or minority.

 

The current cardinality on Election / Proposal - I'm not sure how we ended up with this!?  I checked in V4 - and its the same - I agree it makes more sense to allow repeatable Proposal - (especially as we have ##ANY as repeatable!).

 

That looks a small change we can make in the 630 to allow one election definition - and then multiple Proposals inside that.  I can make that quick point change - but I'll wait until after the meeting - so I can make just one V5 revision here - to address whatever is resolved across all the items we have under review.

 

Thanks, DW

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

-------- Original Message --------
Subject: [election-services-comment] more on 630 OptionsList
From: David Mas <david.mas@scytl.com>
Date: Tue, June 12, 2007 6:00 am
To: election-services-comment@lists.oasis-open.org

Hi,
First of all I would like to thank you all for your attention on the
issue of the referendum options internationalization.

In respect of your proposal I agree with you that 'ProposalItem' can
be used for internationalizing but, is it an optimal way of doing it?
Using a 'ProposalItem' seems a denormalization of the data represented
(localized referendum questions and answers): 

Each 'ProposalItem' element can represent a question or answer in one
language, so if we had a referendum question with 3 possible answers
localized in 3 languages, we would need 12 'ProposalItem' elements to
represent it fully (1 question text + 3 answer text times 3 languages
to internationalize). This only goes a little worse because of the
multiplicity of its parent element 'Proposal'. In the end we would
need 12 'Election' elements (each of them with their mandatory
'ElectionIdentifier'). And that is just for a single question!

For the actual development we will use your approach but we also would
like to suggest some improvements on this message for your
consideration:
- As it is now, the 'Election' tag accepts a single element. Wouldn't
it be better to allow it to contain multiple 'Proposal' elements (one
for each contest) inside the 'Election'?
- Also, the 'Proposal' could allow to define all its related answers
(Options) inside, by using a 'MessagesStructure' which is the perfect
element to allow internationalization.
- Please note that these do not imply the suppression of the
identifier elements, and simplifies the structure (and thus the
parsing and generation) of the message.

Regards,


-- 
David Mas Santaló, Senior Software Engineer

e-mail: david.mas@scytl.com
phone:  +34 934 230 324
fax:    +34 933 251 028

Scytl Secure Electronic Voting
C. Tuset 20 1-7
08006 Barcelona, Spain
http://www.scytl.com 


NOTICE: The information in this e-mail and in any of its attachments is
confidential and intended solely for the attention and use of the named
addressee(s). If you are not the intended recipient, any disclosure,
copying, distribution or retaining of this message or any part of it,
without the prior written consent of Scytl Secure Electronic Voting SA,
is prohibited and may be unlawful. If you have received this in error,
please contact the sender and delete the material from any computer. 



This publicly archived list offers a means to provide input to the
OASIS Election and Voter Services TC.

In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.

Subscribe: election-services-comment-subscribe@lists.oasis-open.org
Unsubscribe: election-services-comment-unsubscribe@lists.oasis-open.org
List help: election-services-comment-help@lists.oasis-open.org
List archive:
http://lists.oasis-open.org/archives/election-services-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=election