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] Re: Moving Forward with EML v5.0

   Thanks John.  Good call. We will consult as staff, and you are 
correct that your answer will come from Mary.  Best regards and 
thanks for all the great work.  JBC

John Borras wrote:
> OK folks I'm going to knock this discussion on the head.  It's
> getting us nowhere.
> Mary - please give us a ruling, are we to conduct another public
> review or not, if so let's get on with it, if not then everyone
> accept the ruling and we proceed to ballot for Commtitee Spec.
> No wonder I'm turning into Mr Grumpy!!
> John
> */"David RR Webber (XML)" <david@drrw.info>/* wrote:
>     Robin,
> Understood. It's back to the statement then - "(gg) "Substantive
> Change" is a change to a specification that would require a 
> compliant application or implementation to be modified or
> rewritten in order to remain compliant."
> And - require - is the key word.  Incidental changes to optional 
> parts would not require someone to change their application.  For
>  example adding a type value to support say a sub-varient of US 
> voting procedures.  Most US implementations and certainly all
> non-US implementations would not be impacted.
> Therefore those applications could continue to pass compliance
> testing without modification.
> Assuming what you mean here by "compliance" is just that the XML 
> they use can be opened and checked against the XSD schema without
>  causing an error message.
> The other case is what I was noting - that people can choose to make
> use of the new items without disrupting everyone else.
> The bottom line procedurally here is that the requirement is to 
> protect participants against unexpected or secret changes being
> made - or changes that they object to and want to enforce a
> public review of.  As I said neither appears to be the case.
> Quite the reverse - we're keen to move forward with adoption
> without further procedural delay.
> If we have another review people are going to think there is 
> something remaining that is substantive that requires their 
> attention.  Unless its accepted that any change is counted by
> OASIS as substantive - and triggers another round of review - and
> hence this diminishes peoples regard for reviews in the first
> place. Afterall - as part of the next step on voting this is all
> going to be open for acceptance and comment again too!
> * * *
>>   Subject: RE: [election-services] Re: Moving Forward with EML v5.0
>>  From: Robin Cover <robin@oasis-open.org>
>>  Date: Sat, July 28, 2007 2:19 pm
>>  On Sat, 28 Jul 2007, David RR Webber (XML) wrote:
>>         >  Robin, * * * [Robin quotes David] * * *
>>    Hi David. Many thanks for your response.
>> Please understand that I have no vested interest here, and that I
>> am  only attempting to understand the meaning and significance of
>> a particular part of the TC Process: its definition * * *
>> * * * [Robin says a lot more] * * *
>> I see **lots of changes** between XML Schemas in A and B (not 
>> just three), but I think we should be able to settle the question
>>  about "Substantive Change" by examining just one construct from
>>  the EML core XML schema * * *
>> * * * [Robin says a lot more] * * *
>> If you disagree with that reasoning, perhaps we need to refer the
>> question to a broader range of opinion or authority (as to which,
>> I have none).
>>         Thanks, Robin
>> * * * [Robin's footnote partially omitted] * * *
>> Our TC Process is meant to protect the interests of everyone --
>> not just the interests of TC members, and not just the interests
>> of other OASIS members (perhaps not in the TC). * * * Independent
>> of that rationale and axiological principle, I think the TC
>> Process needs to be followed and enforced: selective adherence
>> and enforcement only serve to create disrespect * * *
>>> * * *
>>>  [Robin's earlier msgs to TC omitted] 

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