At 2009-11-30 23:22 +0100, JAVEST by Roberto Cisternino wrote:I see, but please try to see this case from the other side:
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.
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.
I agree.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".
Starting wih the creation of the extension there is no change of meaning and both the IDs meaning are respected.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.
About schema validation I think this is something for the 2nd value validation step (schematron/xslt) and not for the structure.
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)
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.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.
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
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
Nessun virus nel messaggio in arrivo. Controllato da AVG - www.avg.com Versione: 8.5.426 / Database dei virus: 270.14.87/2536 - Data di rilascio: 11/30/09 07:31:00
--
PPlease consider the environment before
printing this email.
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 |