Paul,
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?
Thanks, DW
-------- Original Message --------
Subject: RE:
[election-services] EML v5 and xs:any
From: "Paul Spencer"
<>
Date: Wed, June 07, 2006 11:02
am
To: "David RR Webber (XML)" <>
Cc: "eml"
<>
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:]
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"
<>
Date: Wed, June 07, 2006 6:26
am
To: "eml" <>
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
