RE: [election-services] EML v5 and xs:any

I was kinda expecting your reply.

This is such a religious / philosophical issue. I guess we've already got one trouser leg down, so what does the other one matter now?!

Ideally you want to have an extension mechanism that propagates back into our standard process. Just allowing people to create "whatever" is obviously potentially problematic - and especially if we are claiming that we're establishing a set of methods that establish interoperability between voting implementations.

UBL of course has taken one path - which is the exact opposite - thou shalt only use our prescribed elements and components - and we are the source of all things and all knowledge.

OAGi took a hybrid route - where they have an explicit <UserExtensions> section in each schema.

I would prefer something that had more of a formal ability to define an <include extension="[URL]"/> type approach.

I guess we can use the XSD import mechanism to pull in such type definitions? Are we giving guidelines on how this should be done? I'd feel more comfortable if there was a more formal way of going about this - that way software can be tuned to support the exact method - and therefore potentially dynamically adjust to such local extensions.

Also - then the <import name="[URL]"/> components can be formally contributed back to us - so we can catalogue those - rather than people creating their own modified versions of our core schemas.

And of course we may choose to incorporate direct support for certain aspects then into future versions.

Similarly this makes upgrading from say V4.0 to V5.0 EML a much simpler process... just adding <import /> statements.

Is this in-line with what you are thinking?

-------- Original Message --------
Subject: RE: [election-services] EML v5 and xs:any
From: "Paul Spencer" <paul.spencer@boynings.co.uk>
Date: Wed, June 07, 2006 11:02 am
To: "David RR Webber (XML)" <david@drrw.info>
Cc: "eml" <election-services@lists.oasis-open.org>

In the UK CORE project, we extend the VoterInformation element to include a VoterEligibilityDate element. We would have extended the PreferredChannel to say what election types the channel was being used for (parliamentary or local). There was no xs:any, so we had to define our own PreferredChannel element instead (in another namespace) and use the xs:any of VoterInfomration to add this. There are several other examples in this project.

Regards

Paul

-----Original Message-----
From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: 07 June 2006 13:40
To: Paul Spencer
Cc: eml
Subject: RE: [election-services] EML v5 and xs:any

Paul,

Can you give a quick simple use case where someone would need this to illustrate its purpose?

Thanks, DW

-------- Original Message --------
Subject: [election-services] EML v5 and xs:any
From: "Paul Spencer" <paul.spencer@boynings.co.uk>
Date: Wed, June 07, 2006 6:26 am
To: "eml" <election-services@lists.oasis-open.org>

I have been looking through EML, and many complex data types (such as for
Voter Information) are extensible through the use of xs:any, while many
others (such as for Agent) are not. Since it appears to have no
disadvantages, I propose to add <xs:any namespace="##other" minOccurs="0"
maxOccurs="unbounded"/> to every global complex type. Does anyone have a
view on this? Responses by Friday please.

Regards

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

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. You may a link to this group and all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

election-services message