MHonArc v2.5.0b2 -->
ubl message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: qDT Spreadsheet- columns and meanings
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/
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]