RE: [election-services] Re: Moving Forward with EML v5.0

-------- Original Message --------
Subject: RE: [election-services] Re: Moving Forward with EML v5.0
From: Robin Cover <robin@oasis-open.org>
Date: Sat, July 28, 2007 2:19 pm
To: "David RR Webber (XML)" <david@drrw.info>
Cc: Mary McRae <mary.mcrae@oasis-open.org>, EML TC
<election-services@lists.oasis-open.org>, Robin Cover
<robin@oasis-open.org>

On Sat, 28 Jul 2007, David RR Webber (XML) wrote:

> Robin,
>
> Simply put - in the end the schema changes related to minor corrections.
>
> V4 code was already looking at changes regardless to take advantage of V5. Key though is the fact that those substantive
> changes were already there in the initial V5 call for review schemas. In fact after the comment period we made only 3
> corrections. Its a mute point if any V4 code that had already been modified to V5 draft would need to be changed at that
> point any more; it could be compliant at that point. We specifically set aside new work on a new 530 statistics schema
> until a future release.
>
> My personal sense here is that there is no value in a further public review. The prior comments raised were already
> addressed and agreed. Also - the new approach to documenting every detail of schema changes with logs may appear more
> substantial than the actual impacts actually are. Individual developers are definately able to access more immediately
> the impacts on their own implementations.
>
> If we had outstanding critical issues that required further input and discussion then it would make sense, or if we had
> introduced brand new schemas. With completion of the V5 we have reached a stable point that should carry us forward.
> Future work toward an entirely new V6 and an overhaul in the information model is the next challenge.
>
> Thanks, DW

Hi David. Many thanks for your response.

Please understand that I have no vested interest here, and that I am
only attempting to understand the meaning and significance of a
particular part of the TC Process: its definition of "Substantive
Change". EML 5.00 (Public Review specification) vs. EML 5.05
seems like a reasonable test case for what is meant by our rules.

I think I understand everything you say above:

* "My personal sense ... there is no value in a further public review"
* "V4 code was already looking at changes" whose v4 code? yours?
application code you happen to know about? below [1a]
* the schema changes related to "minor corrections"

However, I fail to hear an explanation which addresses my exact
question and the actual terms of the TC Process. The TC process
does not know about "no value in a further public review" or
a specific closed set of applications known to members of the TC,
or about XML Schema changes thought by one person to be "minor".

It's fundamentally irrelevant whether one person (or another) would feel
that XML schema changes from the PR version to current version represent
"minor" corrections or not. It's also irrelevant, as I understand the
rules, whether the XML schemas are "brand new" or not. It's also
immaterial IMO whether there are three changes or thirty. The claim
that "Individual developers are definately able to access more immediately
the impacts on their own implementations" is interesting, but irrelevant
to the TC Process as far as I know.

The focus of my question is on a single matter: the TC Process definition
of "Substantive Change"

(gg) "Substantive Change" is a change to a specification that would
require a compliant application or implementation to be modified or
rewritten in order to remain compliant.

Please also note the two endpoints that are relevant to "change":

TC Process requires (3.2. Public Review) that NO changes be made
during the PR period:

"No changes may be made to the Public Review Draft during a review.
If changes are required the specification must be withdrawn
from review then resubmitted."

The PR period ran from 11-April-2007 through 10-June-2007: it appears
that several changes to the XML schemas were made during that
period.

TC Process also requires (3.2. Public Review) that

"If Substantive Changes are made to the specification after the public
review, whether as a result of public review comments or from TC
Member input, then the TC must conduct another review cycle.

The period "after the public review" extends from June 11 through
current, including the most recent release of the XML schemas (known to
me): 30-June-2007 available here
http://www.oasis-open.org/committees/download.php/24519/EML-v5-0-schemas-070629.zip

The relevant endpoints for comparing XML schemas to determine whether
there are "Substantive Change"s, then, are

- A (timestamps 2007-04-03 as submitted for Public Review)
- B (timestamps various from 2007-06-29 and earlier)

as presented here, if I have made no mistake

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

A: XML Schema file timestamps: 2007-04-03 as submitted for Public Review

http://docs.oasis-open.org/election/eml/v5.0/cd01/EML-v5.0-cd01.zip
http://docs.oasis-open.org/election/eml/v5.0/cd01/EMLv5.0Schemas/
http://lists.oasis-open.org/archives/election-services/200704/msg00007.html
http://lists.oasis-open.org/archives/tc-announce/200704/msg00014.html

10300 2007-04-03 15:03 110-electionevent-v5-0.xsd
5822 2007-04-03 15:04 120-310-330-include-v5-0.xsd
8223 2007-04-03 15:05 120-interdb-v5-0.xsd
5938 2007-04-03 15:04 130-480-include-v5-0.xsd
5275 2007-04-03 15:04 130-response-v5-0.xsd
8239 2007-04-03 15:04 210-nomination-v5-0.xsd
6027 2007-04-03 15:04 220-nominationresponse-v5-0.xsd
7187 2007-04-03 15:03 230-candidatelist-v5-0.xsd
5298 2007-04-03 15:04 310-voterregistration-v5-0.xsd
9291 2007-04-03 15:04 330-electionlist-v5-0.xsd
10617 2007-04-03 15:03 340-410-430-include-v5-0.xsd
10204 2007-04-03 15:05 340-pollinginformation-v5-0.xsd
5660 2007-04-03 15:05 350a-outgoinggeneric-v5-0.xsd
5660 2007-04-03 15:05 350b-incominggeneric-v5-0.xsd
5660 2007-04-03 15:05 350c-internalgeneric-v5-0.xsd
5883 2007-04-03 15:05 360a-outgoingchanneloptions-v5-0.xsd
5795 2007-04-03 15:05 360b-incomingchanneloptions-v5-0.xsd
5603 2007-04-03 15:05 410-ballots-v5-0.xsd
5774 2007-04-03 15:06 420-authentication-v5-0.xsd
5960 2007-04-03 15:06 430-authenticationresponse-v5-0.xsd
7556 2007-04-03 15:03 440-460-include-v5-0.xsd
5601 2007-04-03 15:01 440-castvote-v5-0.xsd
5876 2007-04-03 15:02 445-retrievevote-v5-0.xsd
5952 2007-04-03 15:02 450-voteconfirmation-v5-0.xsd
6828 2007-04-03 15:02 460-votes-v5-0.xsd
7278 2007-04-03 15:02 470-vtokenlog-v5-0.xsd
7823 2007-04-03 15:02 480-auditlog-v5-0.xsd
9606 2007-04-03 15:03 510-count-v5-0.xsd
7592 2007-04-03 15:04 520-result-v5-0.xsd
6658 2007-04-03 15:03 610-optionsnomination-v5-0.xsd
5880 2007-04-03 15:00 620-optionsnominationresponse-v5-0.xsd
5901 2007-04-03 15:04 630-optionslist-v5-0.xsd
45350 2007-04-03 15:03 emlcore-v5-0.xsd
7245 2007-04-03 15:04 emlexternals-v5-0.xsd

B: XML Schema file timestamps: 2007-06-69 and earlier

http://lists.oasis-open.org/archives/election-services/200706/msg00030.html
http://www.oasis-open.org/committees/download.php/24519/EML-v5-0-schemas-070629.zip

48921 2007-06-29 16:22 emlcore-v5-0.xsd
1755 2007-06-29 15:13 630-optionslist-v5-0.xsd
6451 2007-06-29 13:07 110-electionevent-v5-0.xsd
6550 2007-06-29 12:56 340-410-430-include-v5-0.xsd
3372 2007-06-15 15:33 440-460-include-v5-0.xsd
5749 2007-05-29 12:44 510-count-v5-0.xsd
2871 2007-05-22 12:21 230-candidatelist-v5-0.xsd
982 2007-02-08 14:55 310-voterregistration-v5-0.xsd
2929 2007-02-08 07:35 emlexternals-v5-0.xsd
1566 2007-02-08 07:34 620-optionsnominationresponse-v5-0.xsd
2342 2007-02-08 07:34 610-optionsnomination-v5-0.xsd
3507 2007-02-08 07:34 480-auditlog-v5-0.xsd
2962 2007-02-08 07:34 470-vtokenlog-v5-0.xsd
2512 2007-02-08 07:34 460-votes-v5-0.xsd
1636 2007-02-08 07:34 450-voteconfirmation-v5-0.xsd
1560 2007-02-08 07:34 445-retrievevote-v5-0.xsd
1287 2007-02-08 07:34 440-castvote-v5-0.xsd
1644 2007-02-08 07:34 430-authenticationresponse-v5-0.xsd
1458 2007-02-08 07:34 420-authentication-v5-0.xsd
1287 2007-02-08 07:34 410-ballots-v5-0.xsd
1479 2007-02-08 07:34 360b-incomingchanneloptions-v5-0.xsd
1567 2007-02-08 07:34 360a-outgoingchanneloptions-v5-0.xsd
1344 2007-02-08 07:34 350c-internalgeneric-v5-0.xsd
1344 2007-02-08 07:34 350b-incominggeneric-v5-0.xsd
1344 2007-02-08 07:34 350a-outgoinggeneric-v5-0.xsd
5888 2007-02-08 07:34 340-pollinginformation-v5-0.xsd
3907 2007-02-08 07:34 120-interdb-v5-0.xsd
1711 2007-02-06 20:21 220-nominationresponse-v5-0.xsd
3923 2007-02-06 20:20 210-nomination-v5-0.xsd
959 2007-02-06 20:20 130-response-v5-0.xsd
1622 2007-02-06 20:20 130-480-include-v5-0.xsd
1506 2007-02-06 20:19 120-310-330-include-v5-0.xsd
3276 2007-02-06 20:09 520-result-v5-0.xsd
4975 2007-02-06 19:55 330-electionlist-v5-0.xsd

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

I see **lots of changes** between XML Schemas in A and B (not just three),
but I think we should be able to settle the question about
"Substantive Change" by examining just one construct from the
EML core XML schema

** From "A" Public Review 'emlcore-v5-0.xsd'

grep -i 'name="party' emlcore-v5-0.xsd

<xs:element name="PartyIdentifier" type="PartyIdentifierStructure"/>
<xs:complexType name="PartyIdentifierStructure">
<xs:element name="PartyName" type="xs:token"/>
<xs:element name="PartyAbbreviation" type="xs:token"/>
<xs:complexType name="PartyStructure">

grep -i supporter emlcore-v5-0.xsd (no matches)

** From "B" Current schema 'emlcore-v5-0.xsd'

grep -i supporter emlcore-v5-0.xsd

- Renamed Party to Supporter as global change in terminology / name
- Supporter structure items retained - however implementers
are cautioned these are expected to be deprecated in V6 of EML
<xs:element name="Endorsement" type="SupporterStructure"/>
<xs:element name="SupporterIdentifier"
type="SupporterIdentifierStructure"/>
<xs:complexType name="SupporterIdentifierStructure">
<xs:element name="SupporterName" type="xs:token"/>
<xs:element name="SupporterAbbreviation" type="xs:token"/>
<xs:complexType name="SupporterStructure">
<xs:element ref="SupporterIdentifier"/>
<xs:enumeration value="supporterlist"/>

grep -i 'name="party' emlcore-v5-0.xsd (no matches)

Please forgive the repetition, but my question is very simple:

In what sense will an application or implementation which
fully supports the 'Party' construct in "A" -- using elements
"PartyIdentifier", "PartyName", "PartyAbbreviation" (etc)

NOT need to be modified or rewritten in order to remain
compliant for XML Schema set "B", where 'Party' is
forbidden and 'Supporter' is introduced?

An EML 5.00 application or implementation which allows (and
otherwise supports) 'Party' will NOT be compliant with
the EML 5.05 specification which disallows 'Party'.

But that's just one of the several changes in XML
schemas between "A" and "B". From my understanding of
the TC Process definition, any one of them will
constitute a "Substantive Change".

If you disagree with that reasoning, perhaps we need
to refer the question to a broader range of opinion
or authority (as to which, I have none).

Thanks,

Robin

[1a] I am interested in one phrase in your explanation

"V4 code was already looking at changes regardless to take
advantage of V5."

This statement seems to correspond to an explanation I heard
second- or third-hand to the effect that the TC members made
an evaluation of EML implementations/applications tracking
with EML 4-5, and determined that for the apps/projects and
developers known to them personally, the relatively "minor"
XML schema changes should not be a problem.

Is that true? Such an evaluation is noteworthy, but
does not fit into the TC Process as far as I know: the
TC Process addresses the definition of "Substantive
Change" in a precise definition that applies to an (any)
implementation or application *in the abstract* -- whether
known to members of the TC or not.

Our TC Process is meant to protect the interests of everyone
-- not just the interests of TC members, and not just the
interests of other OASIS members (perhaps not in the TC).
The stakeholders are also members of the public, with whom
OASIS has a commmunity contract and moral obligation to
uphold that contract.

Independent of that rationale and axiological principle, I think
the TC Process needs to be followed and enforced: selective
adherence and enforcement only serve to create disrespect for the
authority of the OASIS Process.

>
> "The way to be is to do" - Confucius (551-472 B.C.)
>
>
> -------- Original Message --------
> Subject: [election-services] Re: Moving Forward with EML v5.0
> From: Robin Cover <robin@oasis-open.org>
> Date: Sat, July 28, 2007 8:11 am
> To: EML TC <election-services@lists.oasis-open.org>
> Cc: Robin Cover <robin@oasis-open.org>, Mary McRae
> <mary.mcrae@oasis-open.org>
>
>
> Congratulation to all members of the OASIS Election and
> Voter Services TC for reaching several v5.0 milestones.
>
> I have some questions for the TC about its initial
> disposition not to hold another Public Review subsequent to
> the Public Review which ended 10-June-2007. In particular:
> I have not seen any response to Mary McRae's memo of
> July 16, 2007 to the TC [1] citing the OASIS TC Process
> definitions and rules about "Substantive Changes" [2].
>
> I understand from the published minutes of the OASIS
> Election and Voter Services Technical Committee Meeting
> of 19-June-2007 that "overall" the TC members did not feel
> the specification changes made in light of review were
> "substantive" [3]:
>
> "Overall members present were content with the latest
> draft and agreed that the comments suggested did not
> represent substantive changes and therefore felt
> another Public Review was unnecessary."
>
> However, as Mary's memo intimates, the OASIS TC Process
> has a very specific technical definition about that
> constitutes a "Substantive Change" -- which triggers
> the need for another review cycle [4]. The definition:
>
> (gg) "Substantive Change" is a change to a specification
> that would require a compliant application or
> implementation to be modified or rewritten in order
> to remain compliant."
>
> Did the TC use that definition of "Substantive Change" in
> arriving at the feeling that another Public Review was
> unnecessary?
>
> I am having difficulty reconciling the fact that significant
> changes were made in the XML schema files (at least four
> schema files), including numerous cases of renaming
> elements, adding and deleting attributes, etc. over several
> iterations of XML schema editing [5]. In the general case,
> XML schema changes will be "substantive".
>
> For example, we may contrast the XML Schema 'emlcore-v5-0.xsd'
> submitted [6] for Public Review (version 5.00) vs. the most
> recent release of this same schema version 5.05 [7].
>
> As noted in various documents, including the published
> "EML v5 PUBLIC REVIEW - DISPOSITION OF COMMENTS RECEIVED" [8],
> and memo of 08-May-2007 [8a] the TC agreed to remove the
> Party element (change the name to "Supporter") add a Type
> on Affiliation
>
> Version 5.00 (PR) Schema in file 'emlcore-v5-0.xsd' via grep:
>
> ==============================================================
>
> <xs:element name="PartyIdentifier" type="PartyIdentifierStructure"/>
> <xs:complexType name="PartyIdentifierStructure">
> <xs:element name="PartyName" type="xs:token"/>
> <xs:element name="PartyAbbreviation" type="xs:token"/>
> <xs:complexType name="PartyStructure">
>
> ==============================================================
>
> Version 5.05 of the same schema file now contains no reference
> to 'Party', but instead attests type/element component 'Supporter'
>
> ==============================================================
>
> <xs:element name="SupporterIdentifier"
> type="SupporterIdentifierStructure"/>
> <xs:complexType name="SupporterIdentifierStructure">
> <xs:element name="SupporterName" type="xs:token"/>
> <xs:element name="SupporterAbbreviation" type="xs:token"/>
> <xs:complexType name="SupporterStructure">
>
> ==============================================================
>
> Numerous other changes to the XML Schemas have also been made,
> as documented (in part) by the change logs presented in the
> schema release of 30-Jun-2007 [7]
>
> If Company Foo developed an application (implementation) of
> EML v5.0 using the XML schemas and documentation for the
> Public Review release, the application would code operations
> matching names and constraints from the v5.00 XML schemas, and valid
> data conforming to that EML 5.00 specification as implemented
> could contain markup elements "PartyIdentifier", "PartyName",
> "PartyAbbreviation", etc. The application's documentation,
> error handling, UIs, and other features will naturally
> reflect names and constructs implied by the v5.00 XML
> schemas and documented in the XML schema descriptions. However,
> that same data matching EML v5.00 will be *invalid* according
> to the XML schemas of (edited) EML version 5.05; much of the
> application code itself (for UIs, help system) will also
> be made obsolete.
>
> In terms of the OASIS TC Process definition -- it seems to me --
> the EML 5.05 XML Schema changes are indeed "substantive",
> by definition: Company Foo will need to modify (rewrite) its
> application to remain [become] compliant with the EML v5.05
> specification schemas.
>
> If the TC disagrees, can someone kindly offer an explanation?
>
> Thanks,
>
> Robin Cover
>
> [1]
> http://lists.oasis-open.org/archives/election-services/200707/msg00009.html
> "Moving Forward with EML v5.0 - I just wanted to point out the following
> rules in the TC Process..."
>
> [2] http://www.oasis-open.org/committees/process.php#definitions
>
> [3] Minutes
>
> http://lists.oasis-open.org/archives/election-services/200706/msg00025.html
> TC Meeting Minutes (TCminutes2007_06_19.rtf) uploaded
> The document named TC Meeting Minutes (TCminutes2007_06_19.rtf) has been
> submitted by Mr. John Borras* to the OASIS Election and Voter Services TC
> document repository.
> Document Description:
> The minutes of TC meeting held 19 June 2007.
>
> http://www.oasis-open.org/committees/download.php/24445/TCminutes2007_06_19.rtf
>
> EML V5 COMMENTS
> JB outlined the standards approval process for members and said
> the objective following this meeting was to approve v5 as a
> Committee Specification and then an OASIS Standard as per the
> OASIS TC Process Guidelines.
>
> Members present then reviewed the comments received following
> the public review and in turn confirmed their acceptance or
> rejection of the proposed changes. The changes as follows
> were discussed:
>
> a. Party Affiliations - Agreed to withdraw Party and introduce
> a type on Affiliation
> b. Voter ID - Agreed to revise existing VoterID rather than
> having two separate elements. Also agreed the need for some
> commentary in the EMLCore schema and to post some localisation
> examples to explain how to use the ID.
> c. IRV/RVC - Agreed to add to VotingmethodType
> d. CountMetric/CountReport - Agreed to add to 510 and 110
> e. Referendum Item - Agreed to implement proposal
> f. Internationalisation - Agreed to implement a one to many on
> election to item. The existing EML specification handles
> internationalization but it is down to each implementation
> to decide whether they do a single language per message or
> a single language per process.
>
> JB, DW and PS will update and circulate a new version of EML
> v5 with the changes applied to TC members for approval before
> asking OASIS Staff to conduct Committee Specification vote
>
> Overall members present were content with the latest draft
> and agreed that the comments suggested did not represent
> substantive changes and therefore felt another Public Review
> was unnecessary.
>
> [4] TC Process Section 3.2. Public Review
>
> If Substantive Changes are made to the specification after the public
> review, whether as a result of public review comments or from TC Member
> input, then the TC must conduct another review cycle. The specification
> may not be considered for approval by the TC as a Committee Specification
> until it has undergone a review cycle during which it has received no
> comments that result in Substantive Changes to the specification.
>
>
> [5] Changes to XML schemas after release of PR materials
>
> http://lists.oasis-open.org/archives/election-services/200705/msg00020.html
> Groups - EML 5.01 draft changes to link EML600 proposal options usage
> (EML-v5-0-schemas-070522.zip) uploaded. The document named EML 5.01
> draft changes to link EML600 proposal options usage
> (EML-v5-0-schemas-070522.zip) has been submitted by Mr. David Webber
> to the OASIS Election and Voter Services TC document repository.
> Document Description: Draft changes to EML to support referendum and
> proposal items across 200, 300, 400 and 500 series for review.
>
> http://www.oasis-open.org/committees/download.php/24068/EML-v5-0-schemas-070522.zip
>
> http://lists.oasis-open.org/archives/election-services/200705/msg00031.html
> The document named EML 5.02 draft changes to add CountMetric and
> CountReport tracking (EML-v5-0-schemas-070525.zip) has been submitted by
> Mr. David Webber to the OASIS Election and Voter Services TC document
> repository. Document Description:
> Draft changes to EML core to provide a CountMetric structure for additional
> information regarding ValidVotes in 510 reporting. Also ReportingUnit
> extension to provide status for results reporting. Also added option to
> PollingPlace to use status mechanism. These changes are designed to
> support US style reporting of counting - but are extensible to suit any
> geographic polling hierarchy.
>
> http://www.oasis-open.org/committees/download.php/24120/EML-v5-0-schemas-070525.zip
>
> http://lists.oasis-open.org/archives/election-services/200705/msg00036.html
> The document named EML 5.03 draft refinement to CountMetric and CountReport
> tracking (EML-v5-0-schemas-070529.zip) has been submitted by Mr. David
> Webber to the OASIS Election and Voter Services TC document repository.
> Document Description:
> Added ability to define the CountMetrics in the EML 410 - and also to
> control where in the EML 510 those occur via XPath location.
> Fixed metric to be decimal from integer to support percentage reporting,
> and added to TotalCount level in 510.
> Provide ability in 410 to define CountMetrics and counting algorithm Id -
> to permit pre-definition for developers of exactly what is needed in the
> 510 count results tabulations.
>
> http://www.oasis-open.org/committees/download.php/24142/EML-v5-0-schemas-070529.zip
>
> http://lists.oasis-open.org/archives/election-services/200706/msg00003.html
> The document named EML 5.04 draft refinement to complete change requests
> (EML-v5-0-schemas-060629.zip) has been submitted by Mr. David Webber to the
> OASIS Election and Voter Services TC document repository.
> Document Description:
> Review of 5.03 compared to comments and change requests showed outstanding
> items - so 5.04 resolves these:-
> - Corrected Candidate attributes issue
> - Added IRV and RCV to VotingMethodType
> - VoterId / VoterIdentification@Id - no change (allows two approaches)
>
> http://www.oasis-open.org/committees/download.php/24274/EML-v5-0-schemas-060629.zip
>
> http://lists.oasis-open.org/archives/election-services/200706/msg00029.html
> http://www.oasis-open.org/committees/download.php/24516/EML-v5-0-schemas-070629.zip
> Subject: Groups - EML 5.05 committee draft schemas from public
> review change/comments requests (EML-v5-0-schemas-070629.zip)
> uploaded
> From: david@drrw.info
> To: election-services@lists.oasis-open.org
> Date: 29 Jun 2007 20:37:54 -0000
>
> The document named EML 5.05 committee draft schemas from public
> review change/comments requests (EML-v5-0-schemas-070629.zip) has
> been submitted by Mr. David Webber to the OASIS Election and
> Voter Services TC document repository.
>
> Document Description: This release is intended to cover all
> changes relating to the public comment period and discussed
> at the June TC meeting.
>
> Change summary:
>
> EMLCore items:
> - VoterId attribute for type changed to support xsi:type approach
> - Referendum items structure support for 630 and 510
> - Cosmetic change to declarations to make them in alphabetic sort order
> - Added standard OASIS required copyright and use statement text
> EML 630 items:
> - Proposal made repeatable within Election
> EML 410 items:
> - Removed CountMetric
> EML 110 items:
> - Added CountMetric
>
> http://lists.oasis-open.org/archives/election-services/200706/msg00030.html
> Subject: Groups - EML 5.05 committee draft schemas from public
> review change/comments requests (EML-v5-0-schemas-070629.zip) uploaded
> From: david@drrw.info
> To: election-services@lists.oasis-open.org
> Date: 30 Jun 2007 16:57:38 -0000
>
> Added Change logs using DeltaXML
>
> Change summary:
>
> EMLCore items:
> - VoterId attribute for type changed to support xsi:type approach
> - Referendum items structure support for 630 and 510
> - Cosmetic change to declarations to make them in alphabetic sort order
> - Added standard OASIS required copyright and use statement text
> EML 630 items:
> - Proposal made repeatable within Election
> EML 410 items:
> - Removed CountMetric
> EML 110 items:
> - Added CountMetric
>
> http://www.oasis-open.org/committees/download.php/24519/EML-v5-0-schemas-070629.zip
>
> [6] specification v5.0 as submitted for Public Review
>
> http://lists.oasis-open.org/archives/election-services/200704/msg00007.html
> http://lists.oasis-open.org/archives/tc-announce/200704/msg00014.html
>
> [7] EML 5.05 committee draft schemas
>
> http://lists.oasis-open.org/archives/election-services/200706/msg00030.html
> http://www.oasis-open.org/committees/download.php/24519/EML-v5-0-schemas-070629.zip
> Subject: Groups - EML 5.05 committee draft schemas from public
> review change/comments requests (EML-v5-0-schemas-070629.zip) uploaded
> From: david@drrw.info
> To: election-services@lists.oasis-open.org
> Date: 30 Jun 2007 16:57:38 -0000
>
> Added Change logs using DeltaXML
>
> Change summary:
>
> EMLCore items:
> - VoterId attribute for type changed to support xsi:type approach
> - Referendum items structure support for 630 and 510
> - Cosmetic change to declarations to make them in alphabetic sort order
> - Added standard OASIS required copyright and use statement text
> EML 630 items:
> - Proposal made repeatable within Election
> EML 410 items:
> - Removed CountMetric
> EML 110 items:
> - Added CountMetric
>
> [8]
> http://lists.oasis-open.org/archives/election-services/200707/msg00000.html
> EML V5 FINAL CHANGES
> You will see from below that David has now posted the final schema
> changes on the TC website. In addition to those I'm attaching a
> simple text Changes Log to supplement the technical one included
> in David's posting plus a Disposition of Comments document following
> the Public Review. Will you please take time over the next week
> to review all these and satisfy yourselves that they capture all
> the changes that we discussed at the recent TC meeting. Please
> let me have a note of any concerns by Monday 8th July. After that
> date I will proceed to ask OASIS staff to take us through the next
> stage of the approvals process.
> I will complete the changes to the supporting documents, ie the
> Data Dictionary and the Process and Schema Definitions in next few
> days to complement the changes noted above.
> Regards John
>
> http://lists.oasis-open.org/archives/election-services/200707/doc00000.doc
> = 1310476990-EML v5 Public Review Comments - Disposition.doc
>
> http://lists.oasis-open.org/archives/election-services/200707/doc00001.doc
> = 69059534-EML v5 Changes Log.rtf
>
> [8a] Change "Party" to "Supporter"
> http://lists.oasis-open.org/archives/election-services-comment/200705/msg00000.html
> The EML usage of party and affiliation is misleading compared to the US
> election practice and terminology. To resolve this conflict suggested
> course of action is:
>
> a) Rename everything that is labelled "Party" to "Supporter" instead.
>
> b) Add an additional element to Affiliation to indicate a Type token.
> This then can be extensible to include Party and everything else - Party,
> Union, Incumbent, and so on.
>
> c) Make this change in EMLcore so it is reflected everywhere it is needed.
>
>
>
>
>
>

election-services message