Title: Message
I
would second what David has said here.
-
Peter
Peter M Zelechoski, CISSP, MBA-TM
Chairman IEEE P1622
Election Systems
& Software
402-970-1242
-----Original Message-----
From:
David RR Webber (XML) [mailto:]
Sent: Thursday, June
08, 2006 7:24 AM
To: Paul Spencer
Cc:
;
Subject: RE: [election-services] EML v5 and
xs:any
Paul,
Actually I'm not disagreeing here with the need and the approach - I
understand the issues and the need for pragmatism.
What I'm trying to say is - let's make sure we formalize this if we are
indeed going to do this all.
Therefore I'm suggesting we formally use the <import > mechanisms
in XSD. And in fact if every schema has by default an import of
..\localextensions.xsd - at the top after the namespace declarations - and
that is just defaulted to <!-- EMPTY --> then we ensure that we have
pointed people to the approach we want them to use.
E.g. We have an extensions mechanism, here's how it works, when you use
it - please propogate back any extensions to the committee as appropriate -
either as a local best-practice note for your jurisdiction - or as a request
for future enhancement.
If we just stick in #any everywhere in the schema without providing
normative practices on its use - then that will not be good.
So - I'm suggesting if we do this we have a formal normative section in
the specification on "Extensions for Local Practice" or similar - and
spell out exactly how people should do this.
Thanks, DW
--------
Original Message --------
Subject: RE: [election-services] EML v5 and
xs:any
From: "Paul Spencer" <>
Date:
Thu, June 08, 2006 6:12 am
To: <>,
<>
Cc:
<>
Charbel,
I
have now replied to David, which covers some of your
points.
The change I am looking for is to extend the mechanism we are already
using to further data types. David is discussing alternative extension
mechanisms, but I see this as a separate exercise. If we change the
extension mechanism at some point, this becomes a major change and we do it
for all data types. Adding some more now will not affect this. The mechanism
does not need justifying as we have already approved it and are using
it.
If
we do not do this, people have to make far greater alterations in their
customisations than if we do. It is not a big change to
make.
This is emphatically not a UK only issue. It possibly applies least
in the UK, since UK requirements were taken into account in the basic
design.
I
don't think there is any formal feedback from the CORE project. However, we
have CORE developers on the TC, and perhaps they can comment on their
experiences.
Regards
Paul
-----Original Message-----
From:
[mailto:]
Sent: 08 June 2006
10:28
To: ;
Cc:
Subject: RE:
[election-services] EML v5 and xs:any
Apologies for not
being able to join the last oasis meeting!
I wanted to make
few points based on my limited understanding of the need and the value of
the change proposed:
- Do we really
need to do this change? What is the need and can we get away without it at
this stage till we further evaluate? My info is limited but at this point
I am not yet convinced the xs:any is necessary or the best way moving
forward.
- Can we do it
differently? If the answer is yes than we need to justify why we are
choosing this way and not other ways! My understanding so far is we can do
it at least in 3 ways. ?
- If what David
is saying true (allowing people to create whatever) than indeed it will
cause more problems than it is intended especially in the absence of a
detailed guideline and dictionary of using
EML.
- Do we have
access to the outcome of CORE EML implementation phase 1 and get the input
of the suppliers who may have encountered this challenge. I think their
feedback in this case would be valuable to justify the need to do
something.
- Is the change
we are proposing is applicable and needed beyond the UK?
Finally, It
sounds to me this change is not a "must have" but rather a "nice to have".
Is that the case?
Regards
/CA
From: Paul Spencer
[mailto:]
Sent: 07 June 2006 16:03
To: David RR Webber (XML)
Cc: eml
Subject: RE: [election-services] EML
v5 and xs:any
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
This message
is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any
other use of the email by you is
prohibited.
---------------------------------------------------------------------
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
