RE: [ubl-lcsc] Suggested Column changes

["Gregory, Arofan" <arofan.gregory@commerceone.com>]

Title: Suggested Column changes

Mark:

 

I have incorporated your corrections, and added a few of my own. Please review and see what you think. I tried to condense a few things, which hoprefully will be obvious to you.

 

Tim's up next, to provide a modified spreadsheet, and to fix my write-up (make sure you cover internal notes, Tim!)

 

Cheers,

 

Arofan

-----Original Message-----
From: CRAWFORD, Mark [mailto:MCRAWFORD@lmi.org]
Sent: Tuesday, December 04, 2001 12:25 PM
To: Ubl-Lcsc (E-mail)
Subject: [ubl-lcsc] Suggested Column changes

Arofan,

Rather than send you an enumerated list, I went ahead and inserted the columns I thought needed to be there.  I also added comments for most of the headers that conveys what I assume to be the appropriate definitions for that column. 

For the group,

I have sent this via the list so that anyone else that wants to share comments with Arofan can do so.  Please do not use this spreadsheet as normative as Arofan/Tim have the formal action to restructure.

Mark
<<Revised Spreadsheet.xls>>

(1) UBL UID

This is a 9-character string, unique across the entire library, starting with the characters "UBL". For now - and until we can assign unique ideas, which has yet to be determined - use the value "UBL000XXX" for all BIEs.

(2) Entity Name

This is the name of the BIE, which - until we have clearer naming rules - functions as a placeholder. If you are comfortable with the ebXML CC naming rules, you can use them (basically, you combine the ObjectClass, add the Property Term, and then add the Representation term to it). If you don't like these, use the xCBL names for now, or something similar. Names should be unique within the scope of your work, pending better information about naming.

If the component in question is an attribute, precede the name with the string "Attribute:" (Attributes are treated like simple types, but they otherwise require a default value to be supplied.)

(3) Simple Type

If an element directly contains data (string, number, datetime, code, etc.) then the type should be indicated here. These values are strictly the primitive data types: you will say "code" for any enumerated list, even though you know which specific code list you are using. (The specific code list, or other custom data type, would be indicated in the "Property term" column.) A value is only supplied here for those fields that directly contain data - complex structures are not addressed here, and a value of "NA" can be provided.

(4) Complex Type

If an element has substructure - that is, it is an aggregate - then it has a value in this column, identifying which structure defines it's type. In terms of XML Schema, this would be the complex type of the element. In ebXML terms, this can either be the name of an aggregate core component, or - more usually - the name of an aggregate BIE.

(5) Core Component Type

This is the "CCT" from table 6-1 in the CC specification (latest draft). It will not apply to most complex types unless they exist as core components, which most of the aggregate BIEs in xCBL do not.

(6) xCBL Definition

This is the definition from the xCBL documentation. Be aware that many xCBL elements are used in many different places within xCBL, and when documented as the children of other elements, this documentation is specific to that use of the element. If in doubt, use the "main" definition from the screen that describes the element in question and its children. 

(7) Core Component Definition

This is the definition, if any, from the corresponding core component.

(8) Identified Coide Lists and Standards

In those cases where an element or attribute contains an enumerated datatype or other value described in an external standard, then the particular code-list or standard should be identified here. This will not be used much of the time, but should always be filled out for code lists.

(9) Analyst Notes

This is a list of comments, queries and notes made as the work is done.

(10) Complex Type Object Class

Note that this field is only used for complex types, never for simple types, but must always be provided when relevant. It contains the name of the complex type that provides the structure for the element in question. This is the standard "type" for a complex element in XSD or xCBL ("BuyerParty" is of type "Party"). Note that in xCBL, as written in SOX, there is no formal distinction between elements and complex types the way there is in XSD - any element is potentially a type for reuse in SOX/xCBL.

(11) Simple Type Object Class

This field provides information used in the Core Components spec but only pertains to data-containing elements. See the CC spec for an understanding of this property. This should be filled in whenever there is a direct relationship to a CC, and the value should be taken from the "Object Class" property of that CC.

(12) Property Term

This is, in an XSD sense, the customized datatype of a simple type. If I have a simple type that takes a code, this field would give me the UBL name of the code list that provides the allowed values. If I have an element containing a number, such as a TaxAmount, this field would provide the name of the specific numeric structure that that value is expected to be in (10 digits, three decimal points might be described as a "Decimal10_3" datatype in xCBL. The nale provided here would be "Decimal10_3".)

(13) Representation Term

This describes the type of values allowed in a simple type, per the CC spec. For complex types, the existing spreadsheet uses "details," although I prefer "N/A". (This should be addressed by Tim in his edits...)

(14) xCBL Name and Type

The name and type of the element as given in xCBL. Be aware that these may be the same thing in xCBL.

(15) Cardinality Information

This field describes the allowed occurence in the parent element, and has the following values:

1..1 (Irremovable) - means it cannot be removed, even through use of an extension mechanism
1..1 - one and only one, but can be extended away
0..1 - zero or one
0..n - zero or more
1..n - 1 or more
n..m - from n to m occurrences, where n is a lower number than m, and both are positive integers

Query: Should we allow "irremovable" status to be conferred on any child, and not just required ones? I think so.

(16) Contained In - UBL BIEs

Gives the name of any UBL BIEs that contain the element in question. Should at least include the name of the parent elements seen in the analysis sample. In the case of attributes, this should be the name of the element of which the attribute is an attribute.

(17) Contained In - xCBL Elements

Gives the name of any xCBL elements that contain the element in question. Should at least include the name of the parent elements seen in the analysis sample. In the case of attributes, this should be the name of the element of which the attribute is an attribute.

(18) Contains - UBL BIEs

This is a list of the children of the BIE being described, in order, by name, and separated by commas (indicating "followed by") or pipes ("|" - indicating "or"). If children must be grouped, as is the case when a choice is one member of a sequence, use parenthesis to group the elements of the sub-choice or sub-sequence. An example of this would be "if a is followed by a choice of b or c", write: a,(b|c).

Note that the attributes of an element should be listed here, separate from the children, and preceded by the label "Attributes:". If no child elements exist, then use "N/A" (as will be the case with all simple types.)

(19) Contains - xCBL Elements/Attributes

Same as for UBL BIEs, but with xCBL elements and attributes. Can generally be cut-and-pasted from the xCBL documentation.

(20) Attribute Defaults

This is used only for attributes. It provides the default value, which can be any of the following:

"Implied," (meaning optional), "Required," "Fixed," accompanied by a fixed value, or a simple value can be provided.

(21) Core Component UID

This is the UID of the correlated core component, in those cases where a direct correlation exists.

(22) Context Fields (several, as in current spreadsheet):

These describe the known context-specific application of the BIE as described, in each area. may be safely ignored for now.