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

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

Paul,

 

And XML was simple at sometime past....!

 

I believe 3 is the better option - as I much prefer to keep the XML and xsd as simple and consistent as possible, and business logic separate - particularly as context is tough to do with xsd alone.

 

Mentioning the "this means that Schematron (or some other means of enforcement)"

it would be nice in EML 5.0 to also permit use of OASIS CAM for rule templates enforcement.

 

Of course I'm highly biased here, since I chair that TC - but we do have our spec' v1.1 out for member comment right now - and I anticipate it will go to OASIS member vote in February.

 

If anyone wants to try CAM out - Martin has a really cool Eclipse editor - just feed it your sample XML - the download is here - http://www.jcam.org.uk

 

Ok - enough of the shameless plug for CAM!  ; -)

 

Cheers, DW

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

-------- Original Message --------
Subject: RE: [election-services] EML v5 (Technical)
From: "John Ross" <ross@secstan.com>
Date: Wed, December 20, 2006 12:45 pm
To: "'Paul Spencer'" <paul.spencer@boynings.co.uk>, "'eml'"
<election-services@lists.oasis-open.org>

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