Re: [ubl] Re: Making references

[JAVEST by Roberto Cisternino <roberto@javest.com>]

I am not sure we are changing the meaning of the ext:UBLExtension/cbc:ID, in fact we are not constraining the implementer to use a particular ID.  The extensions IDs can be still considered as a primary key for UBL extensions or whatever else.   We just need to recommend that the ID of the extension containing the signature will have to be the same used in cac:Signature/cbc:ID

We could say that cac:Signature/cbc:ID is the foreign key pointing to the UBLExtension primary key.

Do I miss something ?

---
Oriol Bausà ha scritto:

042398CB-7D2B-4F4A-AFAF-5E286AB445FB@INVINET.ORG" type="cite">Hi Ken,

I can agree with all your points,  but the strange think with your solution is that you came out with a new structure to be maintained in UBL, and for the very first time, we are producing structure for an extension point.

We are also creating two different signature components: a common library UBL Signature component and another one that's used as a wrapper inside the extension point. The use of extension points to place the signature was originally thought as a way to incorporate digital signatures of another namespace inside UBL documents without breaking schema compatibility. Extensions where the only place where we could add other stuff than UBL so it was a nice placeholder for this kind of information. All the linkage (ID/IDREF, Xpointer) information is suggested to enable the use of the UBL common library Signature component.

The other question is whether the UBL Signature component has sense or not. Personally, I think that most information in UBL Signature component is also covered in a standard ETSI Signature (XAdES) so you wouldn't need that component at all. Then you would only require to place  the signature in an Extension and no requirements on Signature placeholders for UBL (that's the case BTW of the invoice, required in some legislations in Europe but without the Signature Component in the Invoice structure)

Another possible way of solving this would be to have a Signature component with a "anyType" structure inside to be used as a signature placeholder, but getting rid of all the components about signature (such as Canonicalization Method or Signature Algorithm) and all the reference problems.

<cac:Signature>

<cac:SignatureAttachment>

<ds:Signature>

...

</ds:Signature>

</cac:SignatureAttachment>

</cac:Signature>

I hope this helps!

Oriol

El 30/11/2009, a las 17:28, G. Ken Holman escribió:

For all those reasons, I think we need:

cac:Signature/cbc:ID   ---------reference---------> ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/sig:Signature/cbc:ID

... with an associated:

ext:UBLExtensions/ext:UBLExtension/ext:ExtensionContent/sig:Signature/ds:Signature

But this is only my idea and I would like to hear the opinion of others.  I feel quite confident, though, that my approach would be within the expectations of the committee.

Nessun virus nel messaggio in arrivo.
Controllato da AVG - www.avg.com 
Versione: 8.5.426 / Database dei virus: 270.14.87/2535 -  Data di rilascio: 11/29/09 19:31:00

  

--

JAVEST by Roberto Cisternino

* Document Engineering Services Ltd. - Alliance Member * UBL Italian Localization SubCommittee (ITLSC), co-Chair * UBL Online Community editorial board member (ubl.xml.org) * Italian UBL Advisor

Roberto Cisternino

mobile: +39 328 2148123
skype: roberto.cisternino.ubl-itlsc
[UBL Technical Committee]	http://www.oasis-open.org/committees/ubl
[UBL Online Community]	http://ubl.xml.org
[UBL International Conferences]	http://www.ublconference.org
[UBL Italian Localization Subcommittee]	http://www.oasis-open.org/committees/ubl-itlsc
[Iniziativa divulgativa UBL Italia]	http://www.ubl-italia.org

PPlease consider the environment before printing this email.