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.
