Re: [ubl] questions about UBL spreadsheets

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

please find my personal opinions in-line.


s-takagi@hitachi-system.co.jp wrote:

>Dear UBL-TC,
>
>
>
>JPLSC is going to hold study meeting of UBL.
>
>And now I'm researching UBL and CCTS specifications for the
>
>purpose of preparing the study meeting.
>
>
>
>While researching these specifications, I had some questions and
>
>unclear point about UBL spreadsheets.
>
>
>
>If you have any idea about these questions, please tell me.
>
>
>
>Q1. How shall we give UBL Name (Column A) to every component?
>
>Does UBL Name have naming rules like Dictionary Entry Name?
>  
>
yes, the UBL Names are formed from the Dictionary Entry Name.

the rules are explained in the UBL Naming and Design Rules as follows:

a. rules CTN1, CTN2 , CTN3 , CTN4 and CTN5 define how to name complexTypes.
b. rules ELN1, ELN2, ELN3 and ELN4 then explain how to create element
names from the complexType names.
c. rules GNR1, GNR2, GNR3, GNR4, GNR5, GNR6, GNR7, GNR8 and GNR9 are
then applied.

i leave it for others to explain why it was done this way.

you can get a more immediate explanation by looking at the formula in
the spreadsheet cells. in fact, if you populate the object class,
property term and representation terms correctly, the UBL Name is
generated for you (as is the Dictionary Entry Name) - you dont need to
know the rule. Unfortunately the Excel formula is not quite
sophisticated enough to get all the naming rules (specifically the
abbrevations) so you may find some anomolies which we had to fix manually.

>
>
>Q2. In Core Component Types' spreadsheet, some of supplementary
>
>components have Object Class (Column D) different from  their owner's
>
>one.
>
>In my CCTS understanding, Object Class Terms of properties are usually
>
>same as their owner's one.
>
>I think core component types are special case, and it is a measure to
>
>fit in CCTS's Core Component Type definition.
>
>Is it right?
>
>  
>
yes, when the ebXML team defined Core Component Types they grouped
different object classes into the same CCT.

>
>Q3. In Core Component Types' spreadsheet, every CCT has string "Type" in
>their Property Term (Column H). I think that this string "Type" is
>
>for concatenating to Object Class (Column D) to create Dictionary
>
>Entry Name (Column B), because Dictionary Entry Names for properties
>
>are created in such a way.
>
>Is it right?
>  
>
yes, that it what i understood as well.

>If it is right, I think the string "Type" might be needed both Data
>
>Type's spreadsheet and string "Details" might be needed the other
>
>BIEs' spreadsheet.
>
>  
>
you are correct, there is an inconsistency - for which i am to blame. We
should have given each Data Type a Property Term of Type instead of
simply hard coding it into the name.

but we cannot do this for the Aggregate BIEs becasue the CCTS states:

> [B30] The Dictionary Entry Name of an Aggregate Business Information
> Entity shall
> consist of the name of the Object Class of its associated Aggregate Core
> Component and possibly additional Qualifier Term(s) to represent its
> specific
> Business Context, followed by a dot, a space character, and the term
> Details.

- an ABIE has no Property Term.

>
>Q4. In Core Component Types' spreadsheet, every CCT's parameter has
>
>value (e.g. Content, Identifier, Text...) in their Representation Term
>
>(Column I).
>
>I can't understand what this column means because CCT's XSD have no
>
>information about these representation terms and there are primitive
>
>type definitions at Column K.
>
>What do these Representation Terms mean?
>  
>
The Representation Term for a CCT is taken from the list specified in
the CCTS document.

ISO 11179 defines them as "defines the type of valid values for an
Information Entity."

We take this to mean "only numeric values", "only date values", "any
text values", etc..

With Specialized and UnspecializedDataTypes, a Representation Terms
actually establish which Core Component Type the supplementary component
uses. So the supplementary components known as "AmountCurrencyID" of the
"Amount" UnspecializedDataType could potentially have all the properties
of an "Identifier" Core Component Type. However, in UBL we only want to
know the value of the supplementary components. Using the previous
example, we only want to use the "Identifier. Content" of the
"AmountCurrencyID". So we use column K to define the XSD dataType of the
content of the supplementary component.

>Q5. In Core Component Types' spreadsheet, every CCT's parameter has
>
>XML Schema's built-in datatypes in Data Type (Column K).
>
>I think you assigned these datatypes to CCTS's primitive datatypes.
>
>Are there some rules for these assignments?
>
>  
>
yes, every Representation Term has an equivalent Core Component Type,
Specialized or Unspecialized Datatype.

the XSD datatype in column K is normally the same as the XSD datatype of
the CCT or DT's ". Content" supplementary component. So if the
Representation Term is "Identifier" and "Identifer. Content" is a
normalizedString, then its XSD datatype will be normalizedString. In
other words, the value of any Identifer will generally be defined as an
xsd:normalizedString, the value of any Text component will be
xsd:string, etc.

There is an exception to this (NDR rule [GXS 3]). When there is a
specific XSD datatype that matches the meaning of the supplementary
component itself, we use that. So we don't define "Language. Identifier"
as normalizedString, even though it has a Representation Term of
"Identifer" and "Identifer. Content" is a normalizedString. Instead we
define it as xsd:language. we also use built in XSD datatypes for any of
the content components, such as datetime, date, boolean, etc.

>
>Q6. In Core Component Types' spreadsheet, all of properties have
>
>notation "Supplementary" at Component Type (Column G).
>
>In my CCTS understanding, I wonder if the properties that Property
>
>Term is "Content" might have "Content" at Component Type.
>
>  
>
i can see why you would want to distinguish "Content" as a special case
- because in its XML expression it is where we put the value. it isn't
like the other supplementary components. in fact the CCTS definition is...

> A Core Component, which consists of one and only one Content
> Component, that carries
> the actual content plus one or more Supplementary Components giving an
> essential extra
> definition to the Content Component. Core Component Types do not have
> Business
> Semantics.


unfortunately, we based the component type values on table 8-2 in the
CCTS. this lists all the supplementary components and includes Content
in them.

however, i suggest we consider changing this in future releases.

>
>Q7. I'd like to confirm the relationship among the Data Types
>
>definitions & CCT definition.
>
>I think the Data Type (Column K) is the Dictionary Entry Name of
>
>corresponding CCT for UDT and is the Dictionary Entry Name of
>
>corresponding UDT for SDT.
>
>  
>
yes, there is inheritence here. SDT->UDT->CCT. But it is also possible
for SDT->CCT

>
>And I also think such correspondences is usually expressed with XML
>
>Schema's "restriction". But the Codes in SDT are special cases that
>
>we can't express with "restriction".
>
>
>Is it right?
>
>  
>
i am not sure what you mean by this - can you explain with an example?

>
>Q8. In every ABIE spreadsheet, every ASBIE property's Property Term
>
>is fixed as Associated Object Class (Column M). It seems more
>
>restricted rule than CCTS's one.
>
>Is it an UBL rule?
>
>
>  
>
i wouldn't call this a rule. it is a design principle. in fact, i am not
sure why you would ever want to use a different property term, except to
confuse someone. if you want to clarify the meaning then you would
qualify the property term or the associated object class.

>
>
>
>I'm afraid that these preceding questions might be trivial or basic ones for
>you, and some of them might be defined in UBL specification, though I have
>checked it.
>
>  
>
neither trivial nor basic - we spent many hours on this issues and i
suspect you now realise, we did not always resolve these issues easily.

>
>Thank you,
>
>
>
>Shin
>-----------------------------------------
>Shin Takagi
>Hitachi Systems & Services, Ltd.
>4-11-4, Omorikita, Ota-ku,
>Tokyo, 143-8545 Japan
>Tel:+81-3-3763-5403   Fax:+81-3-3763-0469
>E-mail:s-takagi@hitachi-system.co.jp
>-----------------------------------------
>---------1---------2---------3---------4---------5---------6---------7
>
>
>To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/ubl/members/leave_workgroup.php.
>
>  
>

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