Re: [ubl-security] Re: [ubl] Re: Making references

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

At 2009-12-23 16:17 +0100, Oriol Bausą wrote:
>El 23/12/2009, a las 14:57, G. Ken Holman escribió:
>>My only comment has to do with the identifiers 
>>for extensions.  I strongly feel we cannot 
>>impose any constraints on extension 
>>identifiers.  Their interpretation is solely 
>>for the management of extensions amongst other 
>>extensions.  I firmly believe 
>>ext:UBLExtension/cbc:ID values should not have 
>>any reflection on business objects of any kind, 
>>including signature objects.  It is scaffolding 
>>information, it is not business information.
>
>Hi Ken,
>
>In the actual document there is no use nor 
>reference to an extension identifier,

I agree because I didn't see one in the actual 
document, but that is not what I was referring to in my post.

>so your concern about the identifiers for extensions does not apply at all.

Forgive me, Oriol, but my recollection is that 
Roberto was expressing exactly that constraint in:

http://lists.oasis-open.org/archives/ubl-security/200912/msg00002.html
At 2009-12-01 19:57 +0100, JAVEST by Roberto Cisternino wrote:
>G. Ken Holman ha scritto:
>>At 2009-11-30 23:22 +0100, JAVEST by Roberto Cisternino wrote:
>>>I am not sure we are changing the meaning of the ext:UBLExtension/cbc:ID,
>>
>>Oh?  The definition currently reads:
>>
>>   "An identifier for the Extension assigned by 
>> the creator of the extension."
>>
>>... and that clearly states it is an identifier 
>>for the extension itself, not an identifier 
>>with another semantic for use within the 
>>extension.  It is extrinsic to the extension data.
>I see, but please try to see this case from the other side:
>1) The creator of the extension assignes a unique ID within extensions
>2) the ds:signature content is located into ext:ExtensionContent
>3) The creator of the extension copies the above 
>ID in the cac:Signature/cbc:ID as a valid Signature identifier

I disagreed with Roberto's proposal to work with 
the extension identifier, and I saw reference to that in Andrea's summary.

At 2009-12-23 16:17 +0100, Oriol Bausą wrote:
>The methods of linkage between the cac:Signature 
>component and the extension is two ways (release 0.1 of the document):

Yes, and in your citations there is no reference 
to the identifier of the extension.  Though 
regarding your citations, I personally have no 
desire to use XPointer as I cannot easily see how 
to support it using the tools I use.

And I believe I have refuted the following that you cited:

>·       <cbc:ID> MUST be present and its value 
>MUST be equal to the <ds:Signature> Id attribute 
>above mentioned. This ID provides a simple way 
>to associate the cac:Signature metadata to the 
>effective digital signature details (see “AnySignatureID” in the above sample).

..... because the lexical space for id= and the 
lexical space for cbc:ID are different, so it is 
possible to create a cbc:ID that cannot be 
expressed in an id= value.  Thus, by CCTS 
business object derivation, I suggested that 
there be an association between ds:Signature and 
a *sibling* cbc:ID under a new element, say, 
sig:Signature, to ensure that all lexical values 
used in association with cac:Signature can find 
equivalent values associated with ds:Signature:

    <sig:Signature>
      <cbc:ID>...</cbc:ID>
      <ds:Signature>
        .......
      </ds:Signature>
    </sig:Signature>

But I was carefully reading Andrea's wording here 
where I believe he made reference to Roberto's 
suggestion of explicitly employing the optional extension identifier:

At 2009-12-23 05:14 +0100, Andrea Caccia wrote:
>the ID inside the signature has the constraint 
>to be equal to the ID chosen for the extension.

...which is what I was uncomfortable with.  The 
ID chosen for the extension is chosen for 
extension scaffolding reasons and not for 
signature business reasons.  And it is optional 
and the user may not have need for an extension 
identifier.  And because it is scaffolding and 
not business, it has no role being constrained in 
a profile.  Profiles constrain the business objects, not the UBL scaffolding.

Thus, I would see a complete structure something along the lines of:

  <ext:UBLExtensions>
    <ext:UBLExtension>
      <cbc:ID>...optional identifier solely for the extension...</cbc:ID>
      <ext:ExtensionContent>
         <sig:Signatures>
           <sig:Signature>
             <cbc:ID>...an identifier used also in cac:Signature...</cbc:ID>
             <ds:Signature>
               .......
             </ds:Signature>
           </sig:Signature>
           ...
           <sig:Signature>
             <cbc:ID>...an identifier used also in cac:Signature...</cbc:ID>
             <ds:Signature>
               .......
             </ds:Signature>
           </sig:Signature>
         </sig:Signatures>
      </ext:ExtensionContent>
    </ext:UBLExtension>
  </ext:UBLExtensions>

... though I know some are uncomfortable with my 
use of singular and plural names and relying on 
the namespace prefixes.  I don't care what the 
names are, but I'm very concerned that we keep in 
mind issues of lexical validity and semantic dissociation.

I hope this helps clarify my perspective on 
this.  Sorry, Oriol, if I misled you in my earlier posting.

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

--
UBL and Code List training:      Copenhagen, Denmark 2010-02-08/10
XSLT/XQuery/XPath training after http://XMLPrague.cz 2010-03-15/19
XSLT/XQuery/XPath training:   San Carlos, California 2010-04-26/30
Vote for your XML training:   http://www.CraneSoftwrights.com/o/i/
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/o/
Training tools: Comprehensive interactive XSLT/XPath 1.0/2.0 video
Video lesson:    http://www.youtube.com/watch?v=PrNjJCh7Ppg&fmt=18
Video overview:  http://www.youtube.com/watch?v=VTiodiij6gE&fmt=18
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