[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ubl-lcsc] Suggested Column changes
99F57F955F3EEF4DABA7C88CFA7EB45A03119F98@C1plenaexm04.commerceone.com">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) Sim ple 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.
(1 5) 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 questio n. 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 ge nerally 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.
text/plain QUOTED-PRINTABLE
-- regards tim mcgrath fremantle western australia 6160 phone: +618 93352228 fax: +618 93352142
The objective is to establish the basic information entity of an xCBL element at a conceptual level. For example, with the xCBL element Currency, the fact that there are two sub-elements (CurrencyCoded and CurrencyCodedOther) does not affect that fact that there is one BIE, Currency which is expressed as a code. The xCBL convention of creating "..Other" elements is merely a means of extending code lists, CurrencyCodedOther is not a separate entity. We should try and avoid designing the new structures at present and focus on the analysis of information - the semantic value of the xCBL elements.
One of the important distinctions to make early in this analysis is whether the entity is of a Simple or Complex type. If the entity holds actual data values(string, number, datetime, code, etc.), then it will be a Simple type and likely to map into a single BIE. If the element has sub-elements, then it is a Complex type and likely to map into an Aggregate BIE. The columns to be completed for these two types are different.
To assist in understanding the data structures, UML class diagrams are provided in the starter kit, to help clarify the contexts of various substructures.
Finally, if it helps in your analysis, refer to the ebXML Core Component Dictionary and attempt to match the xCBL elements with entries in the CC Dictionary.
Each heading has a comment describing the purpose and example content of the column.
If you are comfortable with the ebXML CC naming rules, you can apply them (combine the ObjectClass, Property Term, and Representation term).
If you have difficulty classifying under these concepts, then use either the xCBL names, or something that is meaningful to you. We are attempting to harmonize names across teams as we go, so consult with the mailing list if you have issues with a specific name.
If you are not comfortable with "context", then leave the context drivers columns empty and we shall address them during the review.
Each team will then review the catalog of one other team.
The consolidated catalog will then be used to generate a UBL Order structure, expressed in its XML form (as specified by the Naming and Design Rules subcommittee)and submitted for review by both the membership of UBL and the organizations represented by the UBL Liaison subcommitee.
Following this review the revised catalog will form part of the submission for an OASIS standard.
We shall follow a similar process, but with revisions based on experienced gained.
>From here, we should have established a meaningful 'core' library of entities, suitable for being extended to form many other business documents.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC