Re: [ubl] questions about UBL spreadsheets

[s-takagi@hitachi-system.co.jp]

Tim,

Thank you very much for your responding.
I can resolove most of my issues with your help,
but some of them are remaining.

Excuse me for asking you again.

> >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.

I'm sorry that I can't get it and I suppose that I couldn't explain
what I wanted to say.
It shoud be bad question.

In the CCT spreadsheet, the cell of "H2" has the string "Type" as well
as Table 8-1 in CCTS ver.2.01.
At first, I couldn't understand what both property term columns mean,
because I thought property terms were used to tell the meaning of the
property of object class.
But after a while, I assumed that these property term columns show the
secondary part of dictionary entry name of CCT.
i.e. I assumed these both property terms are corresponding to
"the term Type" of the following rule;

[C30] The Dictionary Entry Name of a Core Component Type shall consist
of a Representation Term followed by a dot, a space character, and the
term Type.

Because Dictionary Entry Names for properties are created in such a way.
It's only my personal assumption.
So I am afraid that I should have asked you what these strings "Type" in
property term columns mean.

And if these strings "Type" in property term columns are
corresponding to "the term Type" of [C30], I suppose the string "Detail"
might be also needed at the property term columns in the ABIE spreadsheet.

> >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.

I suppose that the author of CCTS might have distinguished the Content
and Supplementary Component, because the title of table 8-2 is
"Approved Core Component Type 'Content' and 'Supplementary' Components".

> >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 inheritance here. SDT->UDT->CCT. But it is also possible
> for SDT->CCT

I suppose that "SDT->CCT" inheritance might be not possible, because
Figure.2 in UBL specification doesn't show the "import" arrow of
"SDT->CCT".

By this question, I'd like to make sure that "Code. Type" at cell
of "K2" in the SDT spreadsheet is UDT "Code. Type" rather than CCT
"Code. Type".
It is a little confusing.

> >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?

I'm sorry for my bad question.

I think the codelist definition is special case about the
following 2 points;

First, about generation of XSD file.
I think that "UBL-SpecializedDatatypes-1.0.xsd" and XSD files
in the "codelist" directory are generated from the spreadsheet of
specialized datatypes.
The codelist XSD files are containing additional information about
their permissible values that are not defined in spreadsheet.
Though I suppose that text file described in Values (Column S)
might contain their permissible values, I'm not sure.

Second about inheritance,
I think the inheritance of UBL is realized by XML Schema restriction
semantics in XSD files, because "AmountType" in
"UBL-UnspecializedDatatypes-1.0.xsd" is restricted, based on CCT
"AmountType".
Whereas in "UBL-CodeList-AcknowledgementResponseCode-1.0.xsd",
"AcknowledgementResponseCodeContentType" is restricted, based on
"xsd:normalizedString" rather than UDT "CodeType".

So, I think it might be special because that codelist schemas
are not based on UDT schemas in their restriction declaration.

> >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.

yes. it's reasonable.
I slightly felt that it is a little strange that property term column
refer representation term column, because representation term is independent
from property term in CCTS.
It is not serious issue.

> >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.

yes, exactly.
I'm always regarding your past work about these issues
while researching these specifications.

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
-----------------------------------------