Re: XML Matters: Practical XML data design and manipulation for voting systems

From: David Mertz <voting-project_at_gnosis_dot_cx>
Date: Mon Jun 28 2004 - 14:06:13 CDT

"Alan Dechert" <alan@openvotingconsortium.org> wrote:
|A couple of very small quibbles. You say EBIs and REBIs are "not generally
|byte-wise identical

Nope... that's exactly right. They are not *generally* identical. They
are not *prohibited* from being identical, but byte-wise identity won't
be a requirement (at least most likely).

Think especially here of different components, e.g. RII vs. BRP, being
manufactured by different coders, to a spec. It's tough to get a spec
that gives you byte-wise identity in all cases (not impossible, but in
my judgment not worth the extra canonicalization rules). It's easier to
express what you mean by "equivalent" (R)EBIs.

To further this point, consider the following two (R)EBI fragments:

  <contest ordered="No" coupled="No" name="Moose Catcher">
    <selection writein="Yes">Terry Gilliam</selection>

    <selection writein="No">Eric Idle</selection>
  </contest>

and,

  <contest ordered="No" coupled="No" name="Moose Catcher">
    <selection writein="No">Eric Idle</selection>
    <selection writein="Yes">Terry Gilliam</selection>

  </contest>

Given that this is an unordered "M of N" contest, there is no semantic
reason to call these *different votes*. But two different machines
(from different coders; or GUI vs. RII; or BRP versions; etc) might
create one versus the other.

There's no reason to impose a false specificity on the exact byte
sequence that represents that particular vote. The EBI spec can
accomodate either equivalent form (of course, more than anyone, I know
that variations within spec can encode covert channels... but that's a
different issue).

Yours, David...
==================================================================
= The content of this message, with the exception of any external
= quotations under fair use, are released to the Public Domain
==================================================================
Received on Wed Jun 30 23:17:24 2004

This archive was generated by hypermail 2.1.8 : Wed Jun 30 2004 - 23:17:30 CDT