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] BBIE cardinality issues in the latest document model


Tim asked questions in this thread that have been overlooked by PSC and TSC members. And, unfortunately, by me until today when I'm pulling together a package.

Please review the text below and my comments.

At 2013-01-09 15:48 +0800, Tim McGrath wrote:
Thanks for documenting this Ken.

My suggestion are given as follows:

Firstly we go ahead with the changes to the BBIEs following - making them all "0..n" (and subject to the constraint about use of multiple languages):

The above I've done.

I had a second list of items ... those BBIEs that allowed multiple occurrences but were not prose-based constructs:

For the 2.1 additions, I suggest
"Awarding Criterion. Calculation Expression. Text" (new): 0..n
"Awarding Criterion. Minimum Improvement Bid. Text" (new): 0..n
"Awarding Criterion. Weight. Text" (new): 0..n
"Clause. Content. Text" (new): 0..n
"Contract Award Notice. Regulatory Domain. Text" (new): 0..n
"Contract Execution Requirement. Name" (new): 0..n
"Contract Notice. Regulatory Domain. Text" (new): 0..n
"Contracting Party. Activity Type. Text" (new): 0..n
"Contracting Party. Contracting Party Type. Text" (new): 0..n
"Declaration. Name" (new): 0..n
"Evaluation Criterion. Expression. Text" (new): 0..n
"Evidence. Name. Text" (new): 0..n
"External Reference. Hash Algorithm Method. Text" (new): 0..n
"Framework Agreement. Frequency. Text" (new): 0..n
"Item Property. List Value. Text" (new): 0..n
"Item Property. Value Qualifier. Text" (new): 0..n
"Meter Property. Value Qualifier. Text" (new): 0..n
"Meter Property. Value. Text" (new): 0..n
"Party Legal Entity. Company Legal Form. Text" (new): 0..n
"Procurement Project. Name" (new): 1..n
"Requested Tender Total. Monetary Scope. Text" (new): 0..n
"Service Provider Party. Service Type. Text" (new): 0..n
"Telecommunications Service. Roaming Partner Name. Name" (new): 0..n
"Tender Line. Orderable_ Unit. Text" (new): 0..n
"Tender Receipt. Contract Name. Text" (new): 0..n
"Tender. Contract Name. Text" (new): 0..n
"Tenderer Qualification Request. Company Legal Form. Text" (new): 0..n
"Tenderer Qualification Response. Contract Name. Text" (new): 0..n
"Tenderer Requirement. Name" (new): 0..n
"Tendering Terms. Funding_ Program. Text" (new): 0..n
"Tendering Terms. Penalty Clauses. Text" (new): 0..n
"Utility Item. Subscriber Type. Text" (new): 0..n
"Work Phase Reference. Work Phase. Text" (new): 0..n
Are all acceptable.

Tim is accepting all of the above changes ... does anyone have any problems with that? We can always "up" the maximum in a future UBL 2.2 if there is a mistake in reducing the ones above, but I'm going to go ahead. In the future we can raise the maximum, but we cannot lower the maximum (for backward compatibility reasons).

But Tim isn't finished:

The differences from Ken's list are:

"Capability. Evidence Supplied. Identifier" (new): 0..n
"Declaration. Evidence Supplied. Identifier" (new): 0..n
"Tender Preparation. Procurement Project Lot. Identifier" (new): 0..n
"Tenderer Party Qualification. Interested Procurement Lots Identifier. Identifier" (new): 0..n "Transport Equipment. Referenced_ Consignment Identifier. Identifier" (new): 0..n - are acceptable if we accept that we must use multiple identification schemes (the schemeID is not duplicated)

Also, I suspect that:
"Exception Criteria Line. Exception_ Resolution Code. Code" (new): 0..n
and
"Contracting Party. Activity Code. Code" (new): 0..n
- are in error and should be 0..1. Did we mean to allow multiple code lists? If we did then same constraint as with Identifiers (above), we must prohibit duplicate schemeIDs.

Finally, "Status. Condition Value. Measure" (new): 0..n
does not make sense and it should be an ASBIE to Dimension and called "Status. Condition Value_ Dimension. Dimension" (0..n)


I am going ahead with all of Tim's conclusions (the multiple schemes are acceptable; we can't undo this) and recommendations for code lists (multiple code lists are not acceptable; we can undo this in UBL 2.2).

Please advise ASAP if you have any problems with the above recommendations.

. . . . . . . . Ken

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Apr 2013
Contact us for world-wide XML consulting and instructor-led training
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/o/
G. Ken Holman                   mailto:gkholman@CraneSoftwrights.com
Google+ profile: https://plus.google.com/116832879756988317389/about
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal



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