RE: [election-services] EML v5 (Technical)

["John Ross" <ross@secstan.com>]

I also think you should go for the last of the three options.

JR

-----Original Message-----
From: Paul Spencer [mailto:paul.spencer@boynings.co.uk] 
Sent: 20 December 2006 17:18
To: eml
Subject: [election-services] EML v5 (Technical)

I would like an opinion from as many as possible out there.

We have Identifiers, such as in the VoterIdentifiaction, where the data type
varies according to the election type (mainly the country in which a public
election is held). For example, it might be a social security number or an
electoral register number. The data type therefore needs to be part of a
localisation.

I had suggested using an abstract data type for this, so that the instance
must have an xsi:type. Either I am going mad, or this does not work. The
reason it does not work is that simple types cannot be abstract, so this
must be a complex type with simple content, such as an extension of
xs:anySimpleType with no actual extension. The type used in the xsi:type
(for example, usa:SSNtype) must be derived from that. However, because we
are deriving from a complex type rather than the original simple type, we
cannot restrict the facets in a derivation. Or have I missed something?

I thought an alternative would be to use a substitution group. This would
allow you to create a new element in your localisation, then use this
instead of the original type. EML itself would include a simple type for
VoterId, then implementations would substitute something like an SSN for
this. The localisation would therefore cause the element name to change. Is
this a better solution? If so, should we force a substitution, or should be
use the original (VoterId in this instance) to be used instead? This would
have a very lax type. Either way, I would generate an example for the
documentation. Note that, if we do this, I would have to embed the xs:any in
another element to keep the content model deterministic.

The third alternative is to do what I did in the UK for our electoral
registration project. The original element has no data type assigned. The
XML then uses xsi:type to assign a type. However, the schema does not try to
enforce this, instead it is done through the Schematron, which checks both
that there is an xsi:type present and that its value is correct for the
specific scenario (UK electoral registers). However, this means that
Schematron (or some other means of enforcement) must be used if we want any
data type validation of this element. This is 2.2 in the wish list. 2.15
attempted to do it through the schema instead.

If I don't get any strong views, I will go for the last of these options.

Regards

Paul Spencer
Director
Boynings Consulting Ltd
http://boynings.co.uk