Update IDREF to IDREFS

[jdmgoogle]

Many elements of type IDREF also have maxOccurs="unbounded". We should switch these over to IDREFS for a few reasons.

1. An unbounded list of IDREF values is the point of IDREFS;
2. Certain libraries (such as JAXB for Java) work with IDREFS but not an unbounded list of IDREF elements (go figure);
3. The NIST spec will probably be switching over to this as well; and
4. It's a minor change.

Comments? Feedback?

[pstenbjorn]

@jdmgoogle I was under the impression that the use of IDREFS was to refer to a series of ID elements in a single list not that there could be multiple elements with a single IDREF value. So is your suggestion that we have a single element that will contain a collection of reference IDs?

[jdmgoogle]

@pstenbjorn Correct. I may have worded my request awkwardly. For example, in BallotStyle instead of this:

<OrderedContestId>oc0001</OrderedContestId>
<OrderedContestId>oc0002</OrderedContestId>
<OrderedContestId>oc0003</OrderedContestId>
<OrderedContestId>oc0004</OrderedContestId>
<OrderedContestId>oc0005</OrderedContestId>

we'd have this:

<OrderedContestId>oc0000 oc0001 oc0002 oc0003 oc0004 oc0005</OrderedContestId>

[pstenbjorn]

@jdmgoogle in that case, yes, this makes a great deal of sense.

[jungshadow]

@pstenbjorn @jdmgoogle Seconded.

[cjerdonek]

Should the suffix in those names be changed to "Ids" to reflect that it can
be more than one?

On Thursday, January 7, 2016, Jared notifications@github.com wrote:

@pstenbjorn https://github.com/pstenbjorn @jdmgoogle
https://github.com/jdmgoogle Seconded.

—
Reply to this email directly or view it on GitHub
#298 (comment)
.

[jdmgoogle]

It was more than one before, and pretty much any API for parsing the data provided it as a list.

I'm torn, but leaning towards keeping the name as it is.

I'm open to feedback from others, though.

[cjerdonek]

The difference is that before it was multiple elements, and each
element represented a single ID. So the singular "Id" for the element name was
appropriate. In this case, it will be a single element whose value
represents multiple IDs.

On Thursday, January 7, 2016, jdmgoogle notifications@github.com wrote:

It was more than one before, and pretty much any API for parsing the data
provided it as a list.

I'm torn, but leaning towards keeping the name as it is.

I'm open to feedback from others, though.

—
Reply to this email directly or view it on GitHub
#298 (comment)
.

[jungshadow]

I think @cjerdonek makes a really good point. It's more clear regarding what the element potentially contains (1...n). I'd vote to change the name and update the styleguide to reflect it.