FAQ for UBL Library Content work

How do I get started?

Why am I using a spreadsheet?

The structure into which Business Information Entities identified from the xCBL structures are to be entered is currently an Excel spreadsheet. This spreadsheet is planned to be upgraded to an XML format, allowing us to use an XML based data management tool. We anticipate that this may require a once-off, automated transfer of this spreadsheet data. However, it should not prevent this technology being used in the interim.

What is the approach I should be using?

We propose a top-down approach, each work team taking the highest structure in their set (e.g. OrderHeader) and cataloging this as a BIE (actually, in this case it would be an Aggregate BIE), then moving top-down, left to right through the xCBL3.0 tree. The samples identified in the workshops are left in the initial BIE spreadsheet to demonstrate how this is to be done.

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.

What do the column headings mean?

The column headings will eventually emerge as the schema for our XML library. We have attempted to re-structure the spreadsheet columns to align with the work of the Tools & Techniques and Naming & Design teams.

Each heading has a comment describing the purpose and example content of the column.

How do I name these Entities?

We are still protoyping naming guidelines, eventually these may become the tagnames, but at present the names are simply meaningful references for our internal use.

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.

What about the Context columns?

If you are comfortable with the recognizing and categorizing the context of an entity then use the approriate heading to denote this. If you feel the context drivers are inadequate then note this in the comment of the entry. This way we can verify or extend the context drivers as we go. more details on "context" available here.

If you are not comfortable with "context", then leave the context drivers columns empty and we shall address them during the review.

How do I deal with xCBL attributes?

At this stage we recommend dealing with attributes as their own BIEs within an aggregate that will be their 'owning' or parent, element. These attribute-dervied entities will be identifiable by prefixing their name with the string "Attribute:".

What happens when I complete my section of the BIE catalog?

Following each team's work, these BIE sheets will be consolidated and harmonised. Therefore, each team should maintain a master copy of their section of the catalog.

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.

What other documents will be built?

The Invoice document will be the next document structure, followed by the Ship Notice (in xCBL, the ASN)

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.