[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-security] Where to go from here
My last proposal is a vote for (A) trying to fix some of the issues you point out at the end of your email. I agree with you that we can't simply exclude all extensions "a priori", but, in some motivated circumstances, I think this can be acceptable id in agreement with the recipient and acceptable for the rules in force: this is the way i tried to face the issues. Andrea Il giorno 27/ago/2010, alle ore 14.55, G. Ken Holman ha scritto: > 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 > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]