Re: [election-services] Developing EML OSI core foundation tools

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

John,

We're not seeing the same experience here around
Registry and Hermes for ebXML as you are indicating.

Admittedly early adopters took more of a knock on this - but I
believe that now both projects - OMAR and Hermes have
reached critical mass and a stable delivery platform.

Hermes is a better example of packaging so that the average
Java programmer can download the toolset, install it, and
get it running within half a day.  I've personally seen 6 now,
on separate occassions, and with different skill-levels, all
succeed.  Hermes is installed in over 11,000 locations in
China alone - on government servers.

Similarly with OMAR - if you install it to PostGrepSQL - it
will work "out the box".  If you want some different SQL,
etc, it takes more work.  I'm on the registry-dev mailing list,
and we're standing up about one new instance every couple
of weeks - and typically it take newbies - with help from the
group about 3 days to get it running.  There are many more
moving parts to registry.  Total projects using OMAR now
exceed 50 - and NIST now has the fully function XDS server
system it is launching as an open source project later this
month.  It's built on top of Registry 2.1.

I have also managed a 4 man team for 6 months on an
NIH project where we configured 3 prototypes - all
using ebXML - and the *easiest* turned out to be
the open source tools.

Overall therefore I must say that my experience here
is a positive one - that is why I was anticipating that
we can create a SourceForge project with a library
of common EML handling routines that can
provide a foundation from EML-based solutions.

Thanks, DW


----- Original Message ----- 
From: "Borras, John" <John.Borras@legsb.gov.uk>
To: "David Webber (XML)" <david@drrw.info>
Cc: <election-services@lists.oasis-open.org>
Sent: Friday, May 06, 2005 9:36 AM
Subject: RE: [election-services] Developing EML OSI core foundation tools



David

Sorry about the delay in getting round to this.  My initial reaction is very
hesitant. Based on our experiences here in UK on trying to use the open
source version of ebXML Registry then that's a route I would find hard to
support. In that case it has taken an enormous amount of effort and
expertise to try to implement something which actually doesn't do the whole
job.  All in all a waste of time and really doesn't promote good messages on
the work of the TC.  So not a good case study to use as an exemplar.  Not
sure I want a similar label on our TC.

So if we were to pursue this course of action how would be guarantee that we
would get a worthwhile output, what resources are required from the TC, and
should we embark on this before we get much more evidence that we have the
right set of requirements and specifications in v4?

John


----------------------------------------------------------------------------
-----


> Team,
>
> It's been a frustrating week here in the USA, watching the machinations of
> the US vendors and stakeholders as part of the HAVA/TGDC process;
> the State officials are panicing about compliance for the 2006 elections,
> and NIST has not been able to stand up a make real recommendations
> without anything first being approved by the vendor engineering teams!
>
> Essentially all attempts at introduce real progress on trusted mechanisms
> at the foundation of the voting process have been stymied.  Along with
> attempts to introduce EML XML as even an optional solution for
> implementing in obvious areas of the process - such as voting records
> themselves.
>
> Example - VVPAT has made promising progress legislatively - with over
> 20 Sates having pending legislation to require it.
>
> Enter the vendors - with their minimalist market-driven thinking.
> Upshot is proprietary plexi-glass sealed printers
> that capture voting logs into the a sealed bin as part of the DRE unit.
> Needless to say these units are an order of magnitude more expensive
> than a regular simple printer.
>
> And sealed pritners fails true VVPAT on multiple levels; fails to
> enspire any trust whatsoever for voters (just more of the same in terms
> of hidden process); and also fails many of the principles of
> OASIS EML around voter privacy, etc, that came from the
> EU requirements.  Apart from those singificant short comings - the
> way the US is intending to allow VVPAT to be
> implemented is a marvellous idea...
>
> The long and the short of this is that it has become clear to me that
> OASIS EML next requires a solution toolkit that is open source.
>
> We have learned this from ebXML Registry and ebXML Messaging.
> Both have OSI foundation components - that solution providers can
> then take and deliver commercial solutions by tailoring to their local
> marketplace needs.
>
> I would therefore like to hear from members here who would like
> to work with us here in the USA (the IEEE team and the OVC
> - Open Voting Consortium - http://www.openvotingconsortium.org/)
> and develop this as a SourceForge project.
>
> I would also be interested in seeing if we can get EU funding for this,
> and or donations of existing code components to form the underpinning.
>
> I'm suspecting that new EU member countries especially would
> benefit from a collaborative development effort to get this code
> out there.  Also - does say the UK government own rights to
> code it has funded already - that could form an initial 'seed' here?
>
> A resource site hosted by the EU would also be great - but we
> could also use OASIS resources to host a developer discuss list -
> again OASIS is already running several of those.
>
> Assuming that Java is the target environment maybe
> http://www.jEML.org if it is available - or similar - is what I'm
> envisioning here.
>
> Thoughts?
>
> Any takers out there?
>
> Thanks, DW
>
>
> ---------------------------------------------------------------------
> 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
>


-- 
Simon Bain
TENdotZERO
0845 056 3377
44 1234 359090
44 (0) 7793 769 846

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


"The information in this email is confidential and may be legally
privileged.  It is intended solely for the addressee. If you receive this
email by mistake please notify the sender and delete it immediately.
Opinions expressed are those of the individual and do not necessarily
represent the opinion of the Local e-Government Standards Body. All sent and
received email from the Local e-Government Standards Body is automatically
scanned for the presence of computer viruses and security issues."