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

I agree that an extension mechanism that propagates back to the TC is valuable. We have already concluded that there will be some customisations that should be incorporated into core EML and some that will remain local. The UBL approach therefore does not work for us. In v5, we are incorporating some of the extensions we made for the UK CORE project and leaving out others. Is this propagation a technical or a procedural issue?

In EML, extension just at the schema level is not enough. We need to base extensions on each significant object. I am not sure if your <include> mechanism would do this (at least, not without pre-processing the schema).

I am not against changing the extension mechanism in the longer term, but I don't think we can look at this sufficiently in the timescales that John wants for v5. Perhaps I am wrong - could you propose a solution, discuss it and implement it (including the documentation) in a short timescale?

There are many other changes I would like to make, such as developing a proper data model (something that was rejected several years ago on resource grounds). Who is going to provide the resource for any of this? If we try "following the money", who benefits? I am currently working foc with no indication that my company will benefit.

Sorry for the rant, most which does not relate to your comment. Today I am another year older and another year more disillusioned (less illusioned?).

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