Re: [ubl] Re: Making references

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

At 2009-12-01 19:57 +0100, JAVEST by Roberto Cisternino wrote:
>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
>
>Thus, not the opposite process, in fact it seems correct to create 
>the signature instance first and after the reference.

Fine ... but there is a mismatch between the two identifiers by their 
definition.

The definition of ext:UBLExtension/cbc:ID is:

   "An identifier for the Extension assigned by the creator of the extension."

The definition of cac:Signature/cbc:ID is:

   "An identifier for the Signature"

If the user doesn't use the information UBL correctly, I don't see 
that we have to support incorrect use of the defined semantics.  A 
user can use *any* UBL information item incorrectly and it is not up 
to us to prevent it.

Anyway, sig:Signature/ds:Signature is mandatory.  If we make 
sig:Signature/cbc:ID also mandatory then the user won't misplace the 
information and it will end up always in the correct location.

>Starting wih the creation of the extension there is no change of 
>meaning and both the IDs meaning are respected.

I disagree.  ext:UBLExtension/cbc:ID means the identity of the 
extension, not the identity of the signature.

And, if my suggestion to go with one extension point for multiple 
signatures is considered useful by the SC, then users couldn't abuse 
the extension identifier or want to abuse the extension identifier 
because it is obvious it cannot be associated with more than one signature.

>About schema validation I think this is something for the 2nd value 
>validation step (schematron/xslt) and not for the structure.

I disagree.  A mandatory identifier is a matter of syntax.

I do agree that a *matching* identifier is a business rule.  A 
business rule can check that for every one or more 
cac:Signature/cbc:ID values there exists a single matching 
sig:Signature/cbc:ID value.  But the presence of a mandatory 
sig:Signature/cbc:ID identifier associated with the 
sig:Signature/ds:Signature signature is not a business rule but an 
information completeness rule.  Without it the information is not 
completely expressed, let alone completely consistent.

>Is optional like most of UBL IDs because it is up to profiles to 
>decide which constraints are required... and subsetting or 
>restrictions are not mandatory as we could just provide a value 
>validation using Schematron in order to check such ID references 
>(aka: business rules cross-references)

My understanding of the requirement would indicate that *all* 
profiles for signatures would mandate the associated identifier 
(especially because of the lexical space of values).  If *all* 
profiles must make it mandatory, then it must never be optional and 
doesn't sound to me like a profile issue at all.

But that is beside my main point is that the established UBL meaning 
cannot be co-opted by the security SC through edict or practice.

>I do not want to make the ID mandatory in the schema at all... this 
>is a business rule between two parts on the same document.

Then I am confused.  I understood the *existence* of the ID was 
mandatory, thus making it a schema constraint.  You say "between two 
parts on the same document" and that, to me, is a value constraint 
and not an existence constraint.  And I totally agree that a value 
constraint is a business rule and not a schema rule.

At today's UBL TC meeting I suggested that UBL 2.1 be published with 
the optional signature extension point schema pre-packaged and ready 
to use out-of-the-box.  Especially if it meets legal and technical 
requirements for governments today.  And it will illustrate a 
completely thought out extension development, and give UBL users an 
example to follow in their own extension development.

But we need more people on the Security SC to express their opinions 
on this issue.  It would seem that Roberto and I are at an impasse 
and we need other perspectives on the issue.

And if my suggestion to have multiple sig:Signature elements inside 
of the top-level sig:Signatures element, then this confusion for 
improperly using the extension identifier disappears.

Would other members please express their assessment of the situation?

Thanks!

And thank you for your patience with me, Roberto, as I feel strongly 
the UBL TC is making some exemplary precedents with the decisions we 
make on this issue.  I feel we cannot be seen to be breaking our own 
established rules.

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

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