OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

election-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [election-services] EML v5 and xs:any

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" <paul.spencer@boynings.co.uk>
Date: Thu, June 08, 2006 6:12 am
To: <charbel.aoun@accenture.com>, <david@drrw.info>
Cc: <election-services@lists.oasis-open.org>

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.
-----Original Message-----
From: charbel.aoun@accenture.com [mailto:charbel.aoun@accenture.com]
Sent: 08 June 2006 10:28
To: paul.spencer@boynings.co.uk; david@drrw.info
Cc: election-services@lists.oasis-open.org
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?




From: Paul Spencer [mailto:paul.spencer@boynings.co.uk]
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.





-----Original Message-----
From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: 07 June 2006 13:40
To: Paul Spencer
Cc: eml
Subject: RE: [election-services] EML v5 and xs:any



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" <paul.spencer@boynings.co.uk>
Date: Wed, June 07, 2006 6:26 am
To: "eml" <election-services@lists.oasis-open.org>

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.


Paul Spencer
Boynings Consulting Ltd

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

--------------------------------------------------------------------- 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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]