Re: qDT Spreadsheet- columns and meanings

[Tim McGrath <tmcgrath@portcomm.com.au>]

see my responses inline...

PS
as suggested I will pass onto the list as someone may have further info 
(or corrections) they want to add.


Sylvia Webb wrote:

>Tim,
> 
>I'm trying to complete the final drafts of the uDT and qDT spreadsheets.
>Additionally, I need to create  ss and QA work documentation for Peter and
>Betty Harvey.  I have a few questions that don't seem to be answered in the
>prose for each column. I hope you can help in clearing up the fog for me.
> 
>1) Column D - Object Class - What is UBL's definition for Object Class? It
>seems that the Object Class for the Content Components is different than for
>the SC's.  
>  
>
In general, we use the term Object Class in its object oriented form as 
the Class that defines a set of Objects. This is defined in the CCTS as 
"The logical data grouping (in a logical data model) to which a data 
element belongs (ISO11179)." We understand these logical groupings to be 
either an ACC, ABIE or Data Type.

With ACC and ABIEs we have decided that the logical grouping of 
Aggregates means that the Object Class will be the same for all elements 
in the aggregate. In fact, it is because they share the same Object 
Class that they are an aggregate. This is not a rule of CCTS but it 
makes sense (and has been followed by most other groups working with CCTS).

When we come to apply this to the Core Component Types and Data Types we 
find that the Dictionary Entry Names have been already defined in the 
CCTS. The Object Class parts of these names do differ within one logical 
group. So we have an Object Classes for Code, Code List and Language for 
Supplementary Components all in the same logical aggregate called Code. 
Details. (It does not help that there are typos in the CCTS that confuse 
the names).

Not a lot we can do about this. Two years ago I suggested the CCT group 
may want to rationalize the data model for Core Component Types and Data 
Types but I think we are locked into it now.

>2) Columns H and J - What is the difference in UBL in a DataType Qualifier
>and a Property Term? I'm confused here. I thought the Property Term
>qualified the Representation Term. I can't tell however in looking at these
>spreadsheets.  Is there any Definition for all of them, which we can put
>into the ss as a comment? 
>  
>
Property Terms and Data Types are different things. Each has an option 
to have a Qualifier. Neither qualifies the other. A Qualifier adds a 
specific refinement to the thing it qualifies.

Property Term is part of the naming (semantics) of the component (CC, 
BIE or Supplementary Component).

Data Types are how the component is implemented. In CCTS this is stated 
as "Defines the set of valid values that can be used for a particular 
Basic Core Component Property or Basic Business Information Entity 
Property. It is defined by specifying restrictions on the Core Component 
Type that forms the basis of
the Data Type." These are logical definitions of how to implement these 
components. For example, what you need to put into a Code to describe it.

But clearly we cannot implement Data Types using Data Types - we would 
have a recursive definition. So when it comes to what to put into the 
column called Data Type in the Unqualified or Qualified Data Type model 
we have to think about what is meaningful.

In UBL 1.0 we used this column to specify the W3C Schema Datatypes 
(sorry but they use Datatype as well however it is only one word). For 
example, normalizedString.

Because UBL is only about modeling for W3C Schemas we have no problem 
with this approach. However, Michael Dill make a good point to the Core 
Component Working Group that other modellers should keep the models 
independent of syntax. This is one reason why we have taken them out of 
the current drafts for the qDT and uDT. The other reason is that UBL no 
longer manages the mapping of components to W3C Schema Datatypes - it is 
done by ATG2. If we were to build these into our model they may get out 
of synch with the actual Datatypes used.

>3) Column N - If Value is fixed or default, where is this indicated?  Do the
>UBL schemas know both fixed and default? What is the UBL definition of the
>difference in fixed and default?
>  
>
My version has Column "N" as being "Unique ID" so I am not sure what 
this comment means.

>4) If the value is a enumeration list, do we tell the user what format to
>submit the enumeration list and what information we need to describe the
>codes and their facets?  
>  
>
This is covered by the code list methodology (and examples). When we 
specify the values for components in a code list these are used to build 
a code list schema.

>5) For Value's, where does a user define any facets such as length? Is it OK
>to add the columns with all the facets from the earlier used ss? 
>  
>
We don't use facets in our models so we have removed these columns.

>6) Unique ID - The prose says this is for schema. Since spreadsheets are
>models in UBL, is the Unique ID applicable to the spreadsheets as well?  
>If yes, is the unique ID the same for  a Data Type and all it's Content
>Components and SC's? If yes, shall the entry unique ID be empty for CC and
>SC?
>If no, do all Content Components  and SC's have to have their own ID? 
>Does the unique ID of a CC/SC of a qualified Data Type always need to be
>different from the unique ID of a CC/SC of the unqualified Data Type, on
>which the qualified Data Type is based? or does the unique ID of a CC/SC
>need to be identical as long as there aren't any changes compared with the
>underlying CC/SC?
>
>  
>
This Unique ID came originally from the CCTS and is expressed in the NDR 
rules as:

[DOC1] The xsd:documentation element for every Datatype MUST contain a 
structured set of annotations in the following sequence and pattern (as 
defined in CCTS Section 7):
• DictionaryEntryName (mandatory)
• Version (mandatory):
• Definition(mandatory)
• RepresentationTerm (mandatory)
• QualifierTerm(s) (mandatory, where used)
• UniqueIdentifier (mandatory)
• Usage Rule(s) (optional)
• Content Component Restriction (optional)

We decided not to issue Unique Identifers to components in our library. 
So its appearance here is to satisfy NDR and CCTS and all will be empty. 
Therefore, the answer is no, it is not applicable to the spreadsheets. 
But if it were used, it would apply at the Data Type level (not to 
supplementary components).

We may have left it in because there was some debate in the Code List 
group about using an ID at the Schema level to make it possible for 
external definitions to be keyed to the UBL Schemas. However, I haven't 
kept track on this so I don't know where it stands.


>Finally, if you feel these answers would benefit the TC, or members could
>contribute to the answers, feel free to respond to the list.
> 
> 
>Thanks,
>Sylvia
>
>
>  
>

-- 
regards
tim mcgrath
phone: +618 93352228  
postal: po box 1289   fremantle    western australia 6160

DOCUMENT ENGINEERING: Analyzing and Designing Documents for Business Informatics and Web Services
http://www.docengineering.com/