[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]