Re: Sample instances

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

At 2010-08-14 16:25 +0200, Oriol Bausą Peris wrote:
>El 14/08/2010, a las 14:32, G. Ken Holman escribió:
> > So this leads me to believe that you were 
> able to somehow add those scaffolding elements 
> yourself and then trigger the signature 
> software to embed the actual <ds:Signature> 
> element.  Is this true?  Are we, then, safe to 
> continue with our own wrapper specification and 
> not be obliged to use an existing ODF or OCF 
> wrapper?  If so, this is good news.
> >
>
>Yes, you are true. We are using the scaffolding
>
><ext:UBLExtension>/<ext:UBLExtensions>
>         <ext:UBLExtensionContent>
>                 <odsig:document-signatures>
>
>where the ds:Signature is inserted.

Right ... but my point was that you had to add 
the scaffolding and it wasn't a requirement of 
the signature software to add it for you, which 
means your software doesn't care what the 
scaffolding is, which means we can go with our 
own <sig:signatures> wrapper instead of the 
<odsig:document-signatures> wrapper.

This allows us to have the optional <cbc:ID> 
child, which is an example of using a UBL standard BBIE in the extension.

This will be our first standardized extension and 
an example for other people to follow.

>The sofware developed to sign UBL Documents in 
>CODICE has  another major difference that maybe 
>we could evaluate to add to the Security SC 
>document, the XPATH expressions for the 
>ds:Transform are thought to avoid signing the 
>signature, but there is more than one choice. 
>This could maybe overcome the issue with the here() function.
>
>-  This one does not avoid other signatures 
>being signed:  http://www.w3.org/2000/09/xmldsig#enveloped-signature
>
>-   Avoids other signatures in the document being signed:
>
><ds:XPath xmlns:odsig=” 
>urn:oasis:names:tc:opendocument:xmlns:digitalsignature:1.0”>
>not(ancestor-or-self::odsig:document-signatures)
></ds:XPath>
>
>-   Avoids other signatures in the document being signed:
>
><ds:XPath>not(ancestor-or-self::ds:Signature)</ds:XPath>
>
>-  Avoids other signatures in the document being 
>signed, there is only one  <odsig:document-signatures> in the document:
>
><ds:XPath>
>count(ancestor-or-self::odsig:document-signatures |
>here()/ancestor::odsig:document-signatures[1]) >
>count(ancestor-or-self::odsig:document-signatures)
></ds:XPath>

My understanding of the above is that the 
expression is true when the node returned by the 
here() function is not the current XPath node or 
one of its ancestors.  If the here() function 
returns the current XPath node or one of its 
ancestors, then the count of the union of the 
here() node and its ancestors is the same as the 
count of the current XPath node and the 
ancestors.  If the count of nodes is greater (it 
can never be less because a union never takes 
away nodes) then the here() function is not the 
current XPath node or one of its ancestors so it adds to the count.

> > Can you share with us, Oriol, the effort it 
> took to configure your software to include the 
> extension schema scaffolding in the instance?
>
>Well it is not really complex to add this scaffolding in the instance.

Okay, I take it it was easy, but do you tell the 
software what scaffolding to add or do you add a 
placebo element in your instance and then have 
the software replace the placebo with the actual 
signature?  I am considering adapting the Apache 
digital signature software into a tool and I felt 
the latter would be the most general approach for 
such a utility:  feed the utility with an 
instance with an empty <ds:Signature> element 
(thus providing all of the arbitrary and 
necessary scaffolding) and the utility replaces 
the empty <ds:Signature> with a populated version 
signing everything outside of the arbitrary 
parent element of the empty <ds:Signature>.  The 
utility is then agnostic to the XML vocabulary 
being used, thus working for UBL, ETSI, OCF or ODF conventions.

But writing that utility will have to wait until 
I've done my other 2.1 PRD1 responsibilities.

> > Unless anyone objects, then, I'll proceed 
> with the SGTG schema production for PRD1.
> >
>
>I agree

Thank you again, Oriol and Roberto, for contributing to the discussion today.

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