Re: Making references

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

At 2009-11-30 18:16 +0100, Andrea Caccia wrote:
>If I understood correctly you suggest:
>- to not put any constraint on ext:UBLExtensions/ext:UBLExtension/cbc:ID

Because it is already defined in UBL we cannot change it's current constraints.

>- to add a new e.g. "sig" namespace and a Signature element 
>containing a cbc:ID = cac:Signature/cbc:ID

Yes, to satisfy the lexical requirements for referencing the 
associated ds:Signature from the cac:Signature/cbc:ID.

Also, this morning, with my additional thought that we have:

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

>This way the eventual ID in ds:Signature, the eventual cbc:ID in 
>ext:UBLExtensions/ext:UBLExtension/cbc:ID are not constrained and 
>implementors can use them with their original meaning.

Precisely ... which is to distinguish extensions from each other, not 
to associate content with an extension.

>At this point we can also add some useful property to sig:Signature 
>(this is under our control) for possibly different signature content 
>we can support in future such as detached CMS/CAdES, detached XAdES 
>and so on. We could add a content-type to specify the mime type of 
>the signature and its encoding to support binary signatures.

I suppose so ... I'm unfamiliar with signature technologies.

>On the other hand we are adding some complexity... It's not clear to 
>me at the moment if the added complexity balances the advantages.

I don't think I've added anything that isn't required to solve the 
problem properly at the schema level.  My recommendations now boil down to:

    (1) - associate ds:Signature with the same kind of identifier being
          used in cac:Signature (for lexical reasons)
    (2) - define the one signature extension point to make a home for
          multiple signatures

I don't think that is complex, and I don't think we can do without 
(1) from a technical necessity.

Please do not hesitate to ask more questions for clarification.  I 
hope I'm successfully conveying some of the issues UBL schema 
designers are faced with.

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