[Fwd: [ubl-lcsc] UBL Result Paper of CC Implementation Verification]

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Team,

The forwarded e-mail comes from the UBL Library Content Subcommittee
(LCSC) - it's the results of their recent CCTS Implementation
Verification. Below I've included a summary of each of the issues, with
some comments.

I'm also copying the Registry TC at the request of Monica.

Thanks,
Joe

UBL Comment/Proposal 1: 
----------------------
Relates to our CCTS spec p.12 issue regarding whether "ResidenceAddress.
Details" is an ACC or an ABIE. We questioned the fact that "Residence"
(or potentially another qualifier) does not belong to one of the 8
context categories. 

UBL suggests that "Qualifiers of Object Class and Property Terms should
be divided into two, namely "Context Driver" and "Adjective" Qualifiers.
The "Context Driver" Qualifiers are values from one of the CCTS context
driver categories. The "Adjective" Qualifier is any other value that
qualifies the object class or property term noun.". 

MY COMMENTS: 
In the CCTS spec p.12 example, "Residence" would be considered an
"Adjective" Qualifier.

UBL Comment/Proposal 2: 
----------------------
Addresses how a Data Type is defined. More specifically, gives the
following example:

"For example, "Buyer_ Product. Type. Code" has a fixed length of 3
characters and the "Seller_ Product. Code" has a variable length with a
minimum of 2 characters and a maximum length of 5 characters. Is it now
necessary to define a separate "Data Type" for each of these two BBIEs?
What should the names of such Data Types be?"

MY COMMENTS: 
According to the CCTS spec, it would be necessary to define separate
Data Types for each of these two BBIEs. Each Data Type would be based on
an "Amount. Type" CCT. The first Data Type would have a Content
Component Restriction with a Format Restriction of "Length", and a
Restriction Value of "3". The second Data Type would have a Content
Component Restriction with a Format Restriction of "Maximum Length", and
a Restriction Value of "5". These Data Types would be reusable for
multiple Core Components.

Regarding naming: The UBL document offers 2 approaches - one is specific
to the BBIEs that are ultimately produced, the other more generic (ex:
"3Characters_Code. Type". The CCTS spec is silent on Data Type naming
conventions, and it is out of the scope of our CC Review work. Hopefully
a "best practice" document will emerge on this in the future.

UBL Comment/Proposal 3: 
----------------------
Addresses the use of Data Type qualifiers: "It is nor very clear, how we
can use the Qualifiers of Data Types in the specific BCCs or BBIEs.".

MY COMMENTS:
To date, we've placed the Property Term Qualifier attribute on the BCC
rather than the Data Type, because the Property Term attribute is on the
BCC. However, I think there may be scenarios in which a Data Type may
require a qualifier. I'll be sending a note out about this very soon.

UBL Comment/Proposal 4: 
----------------------
Addresses the difference between the "Code. Type" and "Identifier. Type"
CCTs.

MY COMMENTS:
Does not affect us, as it is more of an issue of how the Core Components
methodology is applied.

UBL Comment/Proposal 5: 
----------------------
Suggests adding new Supplementary Components to CCTs "Code. Type" and
"Identifier. Type".

MY COMMENTS:
Does not affect us in the short term.

UBL Comment/Proposal 6: 
----------------------
Suggests adding new Core Component Types.

MY COMMENTS:
Does not affect us in the short term.

UBL Comment/Proposal 7: 
----------------------
Suggests adding new Representation Terms to Table 8-3.

MY COMMENTS:
Does not affect us in the short term.

UBL Comment/Proposal 8: 
----------------------
Proposes the concepts of "Semantic Packages" and "List Containers"

MY COMMENTS:
Does not affect us in the short term. List Containers are represented by
us as multiple Associations from an ACC/ABIE to another ACC/ABIE. For
the naming concepts (ex: "Items. List"), an implementation could require
the ".List" extension if the Cardinality of an ACC within another ACC
(or ABIE within another ABIE) is greater than 1.

UBL Comment/Proposal 9: 
----------------------
Addresses the overlap between Data Types and Representation Terms (ex:
Data Type of "Text", Representation Term of "Text"). 

MY COMMENTS:
Note comments in UBL document:

"None of this convoluted problems would exist if we simplifed the
meta-model.  The name of the BIEs gives the semantics to identify a
consistent, logical piece of information.  The concern about specific
physical characterics is confusing the real issues of defining semantic,
syntax-neutral, core components."

I believe this echoes some of our sentiments.

UBL Comment/Proposal 10: 
-----------------------
Related to Comment/Proposal #1 - addresses the use of qualifiers for
Object Class Terms and Property Terms.

MY COMMENTS:
None.

--- Begin Message ---

• From: "Stuhec, Gunther" <gunther.stuhec@sap.com>
• To: "'Alan.Stitzer@marsh.com'" <Alan.Stitzer@marsh.com>
• Date: Mon, 18 Aug 2003 09:26:30 +0200

Title: UBL Result Paper of CC Implementation Verification

Hello Allan,

you'll find the results from the UBL LCSC of the CC implementation verification process as an attached file.

Kind regards,

        Gunther

<<UBL Comments for Implementation Verification V1p0.doc>>

UBL Comments for Implementation Verification V1p0.doc

You may leave a Technical Committee at any time by visiting http://www.oasis-open.org/apps/org/workgroup/ubl-lcsc/members/leave_workgroup.php

--- End Message ---

UBL Comments for Implementation Verification V1p0.doc

begin:vcard 
n:Chiusano;Joseph
tel;work:(703) 902-6923
x-mozilla-html:FALSE
url:www.bah.com
org:Booz | Allen | Hamilton;IT Digital Strategies Team
adr:;;8283 Greensboro Drive;McLean;VA;22012;
version:2.1
email;internet:chiusano_joseph@bah.com
title:Senior Consultant
fn:Joseph M. Chiusano
end:vcard