David,
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?).
Regards
Paul
-----Original Message-----
From: David RR Webber (XML)
[mailto:]
Sent: 07 June 2006 19:38
To: Paul
Spencer
Cc: eml
Subject: RE: [election-services] EML v5
and xs:any
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
---------------------------------------------------------------------
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
