[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl] Re: Making references
At 2009-11-30 17:50 +0100, Oriol Bausą wrote:
>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.
Yes, though I was not the one to conceive of this
... I was only asked to comment on the structures proposed to be used.
I think it makes sense to use the extension point
for a few reasons: (1) one scheme can be used
for UBL 2.0 and UBL 2.x, (2) semantically the
signature mechanism could be regarded as
orthogonal to the business information of the
instance (though I admit if we had worked this
out earlier it would have made it into standard
UBL 2.0), and (3) it becomes an exemplar for extensions for our user community.
>We are also creating two different signature
>components: a common library UBL Signature component
That one already existed ... row 898 of the 2.0 common library.
>and another one that's used as a wrapper inside the extension point.
Yes, that one is new.
>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.
Right.
>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.
Agreed.
>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.
Ahhhh, but I tried to document my reasons for
creating the sig:Signature component:
(1) - current referencing in UBL doesn't involve attributes, and
ds:Signature uses an attribute
(2) - the lexical space for cac:Signature/cbc:ID is not the same
as the lexical space for ds:Signature/@id, and so it is
possible users will create a cac:Signature/cbc:ID that would
not be schema valid as a value for ds:Signature/@id
(3) - while the top element of an extension is supposed to be in a
non-UBL namespace, and indeed ds:Signature is in a non-UBL
namespace, but the committee creating the extension is not
in charge of ds:Signature and so doesn't have the opportunity
to evolve the extension definition
And something came to mind this
morning: multiple signatures. Do we need the following:
<ext:UBLExtension>
<ext:ExtensionContent>
<sig:Signatures
xmlns:sig="urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2">
<sig:Signature>
<cbc:ID>*AnySignatureID1*</cbc:ID>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
xmlns:xades="http://uri.etsi.org/01903/v1.4.1#";>
[...]
</ds:Signature>
</sig:Signature>
<sig:Signature>
<cbc:ID>*AnySignatureID2*</cbc:ID>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
xmlns:xades="http://uri.etsi.org/01903/v1.4.1#";>
[...]
</ds:Signature>
</sig:Signature>
</sig:Signatures>
</ext:ExtensionContent>
</ext:UBLExtension>
... which would add a new reason:
(4) - the cardinality of <ds:Signature> is 1 and UBL users need to be
able to specify multiple signatures; yes, they could use multiple
extensions, but is that really the right semantic? Does it not
make more sense to just have one extension for all signatures?
I think reasons (2) and (4) are very compelling.
>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)
Sorry, I'm not sure what you mean by that ... we
already have a requirement in cac:Signature that
it have a mandatory identifier. Please forgive my confusion.
>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>
Unfortunately not because the schema constraints
for cac:Attachment do not provide for XML markup
... it must be a base64-encoded item, and I think
we want <ds:Signature> to be in clear text. The
way cac:Attachment works would require:
<cac:Signature>
<cac:DigitalSignatureAttachment>
<cbc:EmbeddedDocumentBinaryObject>
.....binary data in base64 format....
</cbc:EmbeddedDocumentBinaryObject>
</cac:DigitalSignatureAttachment>
</cac:Signature>
.... and you can see that not only we would "lose
sight" of the fact that it is <ds:Signature> but
that processing applications looking for <ds:Signature> would not find it.
>I hope this helps!
I hope I've been able to present a reasoned aspect of this discussion!
. . . . . . . . . . Ken
p.s. does XML Sig allow me to move the namespace
declarations up in the hierarchy as XML does? As in:
<ext:UBLExtension>
<ext:ExtensionContent>
<sig:Signatures
xmlns:sig="urn:oasis:names:specification:ubl:schema:xsd:CommonSignatureComponents-2"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
xmlns:xades="http://uri.etsi.org/01903/v1.4.1#";>
<sig:Signature>
<cbc:ID>*AnySignatureID1*</cbc:ID>
<ds:Signature>
[...]
</ds:Signature>
</sig:Signature>
<sig:Signature>
<cbc:ID>*AnySignatureID2*</cbc:ID>
<ds:Signature>
[...]
</ds:Signature>
</sig:Signature>
</sig:Signatures>
</ext:ExtensionContent>
</ext:UBLExtension>
... or do signature processing applications need
to see the namespace declarations on the <ds:Signature> element:
xmlns:ds="http://www.w3.org/2000/09/xmldsig#";
xmlns:xades="http://uri.etsi.org/01903/v1.4.1#";
(from an XML perspective they shouldn't need to
see it, but they may not be fully XML aware).
--
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]