RE: [election-services] Fw: EML and ranked-choice elections

["David RR Webber \(XML\)" <david@drrw.info>]

Rich,

 

This is not just a problem for EML - its any schema!

 

Joel touched on this on our call.   What I'm working on with the OASIS CAM toolkit is way more than we've discussed.

 

It does in fact make available what Dave is discussing here.  However - this is all new - we're still refining this - and I'm working now with the OASIS SET folks on aligning to CCTS, NDR and so on, and extending the dictionary capabilities. 

 

Localization is what is comes down to, and of course this has been a central theme for our EML work already.  Making it quick to do in a formal way is the challenge.

 

You can do this with the CAM toolkit right now - but you have to know what you are doing!  What we want to get to is a standardized way - aligned with specifications - and a guide book to instruct folks with - and the tooling facilitate it - crosscheck everything for them.

 

So - having said all that - my goals with V6 here is to have a solid clean and useful schema as a base. 

 

I'm also developing CAM templates for each of the schemas - as you can see from the package I sent out.  This facilitates people creating their own subset localizations and extensions, test case generation, documentation, dictionary crosswalks, et al.  Things that used to take months to do can now be done in a few hours.

 

There is so much more we can do next - but we can't boil too much of the ocean!  Also - there is no need to make dependencies between CAM and EML obviously.  The schema is what it is.  We can just facilitate these other peices for everyone.

 

So I think we take Dave's points as noted - make some obvious tactical enhancements where those make sense - and that should be more than enough for V6.

 

Thanks, DW

 

 

-------- Original Message --------
Subject: Re: [election-services] Fw: EML and ranked-choice elections
From: Richard J Cardone <richcar@us.ibm.com>
Date: Fri, January 23, 2009 10:03 am
To: EML TC <election-services@lists.oasis-open.org>


John and David,

>Election administration is difficult due to the dizzying variety of special rules and constraints imposed by the client organization.  Customization is required in nearly all cases, and the above point is just one >example.  The architecture of EML is quite restrictive in nature, making it very difficult to conform to.  It could, at least, make much more generous use of the "any" elements.  I need EML to be a true language, >and not just a rigid and steeply hierarchical data structure - that is, with a vocabulary and some rules of grammar for assembling simple elements into more complex structures that a standards committee will not >be able to anticipate or keep up with.  If this were the case, I think EML could be much more widely applicable.  I think this is possible to achieve in an XML schema, but I think it would require a change in >course.

The change in course suggested above by Dave Robinson may or may not be practical, but it's probably worth hearing out if for no other reason than Dave is an actual EML user.  Maybe Dave would be willing to take an existing EML schema as an example and show how it could be refactored to increase its modularity and flexibility.  When would then have something concrete to discuss.

Rich