Where to go from here

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

Fellow Security SC members,

With so many concerns expressed regarding my proposal, I have no 
problems stepping away from it and quickly implementing whatever the 
SC decides for PRD1.  It seems over the days that all of the 
participants, including myself, have only repeated their initial 
stances and seem unswayed by the arguments of others.  And that is 
fine ... we all have different perspectives that we are bringing to the table.

As I read this morning's messages, we have to decide between two 
alternatives to what is in the SGTG package today, being between zero 
scaffolding:

(A) Oriol/Roberto/Tim:
   <sig:SignatureInformation>
     <ds:Signature>...</ds:Signature>
     ...
     <ds:Signature>...</ds:Signature>
   </sig:SignatureInformation>

... and generic scaffolding (though because of modeling rules we 
cannot use the proposed plural term and I'm trying to think of 
another singular term):

(B) Andrea:
   <sig:SignatureInformation>
     <sig:Signature>
       <cbc:ID>...</cbc:ID> (optional)
       <sig:SignatureGroup>
         <ds:Signature>...</ds:Signature>
         ...
         <ds:Signature>...</ds:Signature>
       </sig:SignatureGroup>
     </sig:Signature>
     ...
     <sig:Signature>
       <cbc:ID>...</cbc:ID> (optional)
       <sig:SignatureGroup>
         <ds:Signature>...</ds:Signature>
         ...
         <ds:Signature>...</ds:Signature>
       </sig:SignatureGroup>
     </sig:Signature>
   </sig:SignatureInformation>

In my intermediate work I had the above structure but then distilled 
out the signature group that did not have a <cbc:ID> child so that 
one would not have *two* <sig:Signatures> with no <cbc:ID> child 
(when you have two, do both apply to the semantic of not having an 
ID?).  So, in my proposal I had prevented two signature groups from 
having no identifier, using modeling to prevent the ambiguity:

(C) Ken:
   <sig:SignatureInformation>
     <sig:SignatureGroup>
       <ds:Signature>...</ds:Signature>
       ...
       <ds:Signature>...</ds:Signature>
     </sig:SignatureGroup>
     <sig:IdentifiedSignatureGroup>
       <cbc:ID>...</cbc:ID> (required)
       <sig:SignatureGroup>
         <ds:Signature>...</ds:Signature>
         ...
         <ds:Signature>...</ds:Signature>
       </sig:SignatureGroup>
     </sig:IdentifiedSignatureGroup>
     ...
     <sig:IdentifiedSignatureGroup>
       <cbc:ID>...</cbc:ID> (required)
       <sig:SignatureGroup>
         <ds:Signature>...</ds:Signature>
         ...
         <ds:Signature>...</ds:Signature>
       </sig:SignatureGroup>
     </sig:IdentifiedSignatureGroup>
   </sig:SignatureInformation>

This is also our committee's first standardized extension and people 
will be trying to learn from what we do.

My assessment is that proposal (A) is inflexible in expressing any 
associations between the UBL business objects and the signatures 
(I've already shown in another email we cannot use the <ds:Signature> 
identifier for such an association).  Communities of users might want 
to infer associations between business objects and signature 
information.  Future UBL documents might require associations between 
business objects and signature information.

My assessment is that proposal (B) is potentially ambiguous and 
burdens the user community with defining exception handling when 
interpreting what it means to have two unidentified groups.  Or even 
three or more ... is there a relationship implied by two of the three 
if they are adjacent?

I accept that my proposal (C) is unacceptable to committee members 
because of perceived complexity as that has been mentioned time and 
time again.  But I believed all along it addresses the flexibility 
for user communities and future UBL documents, and it is unambiguous 
in preventing multiple unidentified groups, and it is an example of a 
detailed extension that others can follow in creating their own 
extensions.  If documenting the complexity is a challenge, I think 
documenting the exception handling of ambiguity is a bigger challenge.

(C) is implemented and I have time this weekend to implement either 
of the (A) or (B) proposals ... but which is it to be?  Someone 
please decide and direct me.  I hereby withdraw from the decision making.

Sorry, that sounds like pouting and I'm not pouting at all ... I just 
need to deliver something to Jon ASAP.  Please don't interpret my 
comments as negative ... I really don't mind abandoning my proposal 
since not a single member has supported it ... this is a 
collaborative group and I accept my proposal doesn't fly ... happens 
all the time and we are all professionals ... but I need to be told 
what to do in order to give something to Jon, and I need a decision 
as soon as possible, please.  (A) or (B).

Oh, regarding the scope of the signature, I feel we are obliged to 
include non-signature extensions in the signature calculation since 
other extensions will contain business information for some 
communities of users.  We cannot exclude all extensions from the 
signature hash.  So that would be that we must include all 
information outside of the ancestral <sig:SignatureInformation> 
element in both scenarios (A) and (B).

Thanks for the debate.  Please decide and we'll move on with user 
testing.  We can change it all for PRD2 if you wish.

. . . . . . . . . . . Ken

--
XSLT/XQuery training:   after http://XMLPrague.cz 2011-03-28/04-01
Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
G. Ken Holman                 mailto:gkholman@CraneSoftwrights.com
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/o/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal