OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ubl message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [ubl] Re: Making references


At 2009-11-30 23:22 +0100, JAVEST by Roberto Cisternino wrote:
>I am not sure we are changing the meaning of the ext:UBLExtension/cbc:ID,

Oh?  The definition currently reads:

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

... and that clearly states it is an identifier for the extension 
itself, not an identifier with another semantic for use within the 
extension.  It is extrinsic to the extension data.

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

No, not "whatever else".  It is defined to identify the extension, 
implicitly to me "amongst other extensions".

>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

No, because that changes the meaning.  And the cardinality is 
wrong.  We want schema validation to succeed when using the 
extension, so we need sig:Signature to have a mandatory cbc:ID so 
that when it is absent the instance is invalid.

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

No, I think we should say cac:Signature/cbc:ID points to 
sig:Signature/cbc:ID because ext:UBLExtension/cbc:ID is optional and 
likely won't be used since people typically will not have many extensions.

And, now that you are using the word "key", that certainly implies to 
me that the identifier is mandatory ... but that is already implied 
by the earlier discussion that we need a correlation from the body to 
the signature in the extension.

>Do I miss something ?

I'm not sure what it might be ... I've already tried to convey the 
importance of not changing the definitions standardized by the 
committee.  I feel strongly we cannot overload the semantics of 
ext:UBLExtension/cbc:ID, and I don't want to oblige people to profile 
their schemas to make it mandatory (and if they are using other UBL 
extensions they will most likely not want it to be mandatory in the 
schema).  Since we cannot change the definition or cardinality of 
ext:UBLExtension/cbc:ID, then we must introduce our own 
sig:Signature/cbc:ID with its own definition and cardinality.

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]