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.
