Dear Tim McGrath,
Thank you very much for having meeting with JPLSC people on June
14 in Tokyo.
According to the discussion, I summarized to the attached
documents.
(1) Issue list regarding UBL V1.0 specifications
This document is issue list including countermeasures and target
version to correct the issues.
(2) FAQ regarding UBL specifications
These FAQs are obtained by Questions and Answers by e-mail and
discussion on June 14.
If you have any corrections or further advice, please let us
know.
Best Regards,
Yukinori Saito
-----
Original Message -----
Sent: Tuesday, June 08, 2004 12:59 PM
Subject: Re: [ubl] Questions and commnets regarding UBL
Reusable V1.0 (latter half)
Dear Tim McGrath,
Thank you very much for your detailed answers and comments.
I inserted my comments started 'YS:' in your comments.
I would like to discuss these questions and answers when you
will come to Tokyo on June 14 (Monday).
Best Regards,
Yukinori Saito
-----
Original Message -----
Sent: Sunday, June 06, 2004 5:10 PM
Subject: Re: [ubl] Questions and commnets regarding UBL
Reusable V1.0 (latter half)
thank you for your well considered questions. It is very good to see
UBL getting such close review as part of the localization work.
i will attempt a response, but encourage anyone else to jump in with
their opinions...
1.Questions or comments about whole business
documents
1.1Name of ID (Recommendation to improve)
There are many IDs in business documents. Those IDs are BBIE, and are
used for different uses. The UBL names of these BBIE had better to be
changed to specific names. I named the equivalent Japanese business
terms like the following recommendation names.
It is not strictly necessary to call the UBLName (element)
PartyID as long as the ID is the identifier of the object class
(container). This is because of the hierarchical nature of XPath in
XML documents. The ID will be within a Party (Party/ID). So it has a
unique XPath name that an application can use. The reason we do this
abbrevation is to keep element names short - but I agree that without
the 'parent' it is ambiguous to us mere humans. Of course, the
Dictionary Entry Name has the full name (for example Party. Identifier).
So it is quite legitimate to use the full name for translation as an
Alternative Business Term (as you have done) because these translations
are for human readers not applications.
YS: I agree.
1.2Differences between ‘ID’ and ‘Code’.
(Question)
There are many BIEs of ‘ID’ and ‘Code’ in UBL business documents. What
is the policy or rule or classification between them?
This is possibly the longest running question - not just in UBL
but in any business vocabulary. Two years ago we decided that there
was no common understanding of the difference and we made up our own.
Code
A code is a representation of some thing, normally text, abbreviating
it to a shortened, encoded form, and usually of the same consistent
length within a code list. In essence it is an abbreviation. The aim
with a code is that there should generally be one list of codes for the
same concept. It doe not always work out that way, but it would be the
ideal situation.
Identifier
An identifier identifies an occurrence of something or set of
somethings. There is often more than one 'scheme' of identifying the
same thing.
We have tried to keep to this rule - but it is not easy and in reality
people will argue on a case-by-case basis.
YS: Does Code have any relations to CodeList (26 pieces, XSD
file) in UBL V1.0 package?
1.3 OrderLine and LineItem (Question)
What is the difference between OrderLine and LineItem in view point of
usage?
If the BIEs in OrderLine (ABIE) would be integrated to the LineItem
(ABIE), and the OrderLine (ABIE) would be deleted, would it occur some
inconveniences?
An OrderLine is as requested on an Order document. However, if
this requested Item is chnage changed (either by the Buyer or Seller)
we want to retain the original Order Line and note this as a different
Line Item. In effect, OrderLine is a mechanism to describe to
chnaging state of a requested item. Most of the information we
normally expect on an Order Line appears in a Line Item - so what you
suggest would be fine expect we then need a way a chaining together any
substutitions.
YS: Plese teach me how to use OrderLine and LineItem, when you
come to Tokyo.
1.4 Some ASBIEs don’t have associated ABIE.
Many ASBIEs have the associated ABIEs in Reusable BIEs. But some ASBIEs
don’t have associated ABIEs. I don’t understand this reason. Is this
bug or something?
and
1.5 Some ABIEs don’t have associated ASBIE.
Some ABIEs are not referred by other ABIEs via ASBIE. To say another
word, some ABIEs don’t have associated ASBIE.
These two are related and the answer affects several other questions
you posed.
You are correct is stating that an ABIE is a container of BIEs. We
based this rule for containership on the functional dependency of the
BIEs involved. But the way we use these is an important part of the
UBL assembly mechanism and needs explanation.
Firstly, no document or ABIE includes another ABIE. ABIEs only
associate with each other. For example, the Party ABIE is associated
with an Address ABIE. We describe this association as an ASBIE. The
ASBIE defines what is particular about the association of Address with
Party (as opposed to its association with other ABIEs). For example,
how we describe this association, how many times can this association
occur, whether it is mandatory, etc.
We see this in the schemas as the element called Address, within the
complexType called Party, being of type AddressType.
<xsd:element name="Address" type="AddressType"/>
and then...
<xsd:complexType name="PartyType">
containing...
<xsd:element ref="Address" minOccurs="0" maxOccurs="1">
I think this is what you refer to as type (a).
However, sometimes the association is qualified. This means the
association has some specific function that we can explain by
qualifying it's name. For example, the association between Item and
Country is qualified by the term 'Origin' - meaning the Country is the
country of origin for the item. This type of qualification is
essential wehere we have two or more associations between the same
ABIEs (for example Item and Item Identification).
However, what is being re-used here is the 'base' ABIE (Country or Item
Identification). We are re-using exactly the same structures or ABIE,
but within a specific context. So when we come to express this in
schemas we want to re-use CountryType or ItemIdentificationType - not
OriginCountryType or SellersItemIdentificationType. Like this...
<xsd:element name="OriginCountry" type="CountryType"/>
and then...
<xsd:complexType name="ItemType">
containing...
<xsd:element ref="OriginCountry" minOccurs="0" maxOccurs="1">
I think this is what you refer to as type (b). You should find that
DespatchLineReference is a re-use of LineReferenceType qualified by it
being the reference for the goods despatch. It is important to
translate this quaification term as part of the ASBIE definition. I
agree this may now translate into a simple Alternative Business Term
because the qualifiers may not have an exact equivalent. I would
recomment the UML diagrams as a guide to recognizing this use of
association qualifiers.
YS: Thank you very much for your detailed analysis and
explanation.
I think that we had better for us (Localization people) to
distinguish the ASBIE by some signs to classify type (a) and (b).
Because type (a) is much important for us to understand BIEs of UBL
business documents.
And, how to recognize or distinguish between type (a) and (b) on
the translation spreadsheet?
2.1LineItem
(1)TaxTotalAmount (BBIE) had better be changed to
LineItemTaxTotalAmount. Because there is TaxTotalAmount (BBIE) in Order
(business document).
we see this as TaxTotalAmount being re-used in both LineItem and
in Order. It is the same BBIE used in two different contexts. In the
schemas they both refer to...
<xsd:element ref="cbc:TaxTotalAmount" minOccurs="0"
maxOccurs="1">
which is defined as...
<xsd:complexType name="TaxTotalAmountType">
<xsd:simpleContent>
<xsd:extension base="sdt:UBLAmountType"/>
</xsd:simpleContent>
</xsd:complexType>
YS: I understood. But, in localization spreadsheet, I will name
the alternative business term as LineItemTaxTotalAmount to distinguish
TaxTotalAmount and LineItemTaxTotalAmount.
(2)The definition of both
MaximumBackOrderQuantity and MinimumBackOrderQuantity says ‘customer’.
This word should be changed to ‘seller party’. The word ‘customer’ is
not used at any other definitions. And the word ‘customer’ is ambiguous
for definition in the UBL specification.
I would agree with this. it further demonstrates why we need a
controlled vocabulary as part of the transaltion process.
2.2LineReference
(1)This ABIE is not referred by any other ASBIE as name.
(2)I cannot understand the meaning and usage of this ABIE.
It is not referred to by any other ASBIE without qualification. In
fact the ASBIEs DespatchLineReference and ReceiptLineReference
associate the ABIE InvoiceLine with this ABIE.
2.3 LotIdentification
(1)The definition uses word ‘recall’. Is ‘recall’ same to ‘cancel’? If
so, don’t you think the word had better to be changed to ‘cancel’?
I dont think we mean the same as cancel. The lot identification
would be the sort of identifier that RFID does. identifying a
specific occurrence of an item. We may order a specific make and model
of vehicle but the lot identifier would be the chassis number of
one(and only one) actual car. When we say recall we mean that this
provides traceability. A car manufacturer can recall a range of
chassis numbers, etc. So a recall is not a cancellation but a request
to send back the item.
YS: I understood. Thank you.
2.4 OrderLine
(1)Is SubstitutionStatusCode a result by seller party or an instruction
by the buyer party or both?
it would depend on which ASBIE within Line Item is used. Seller
Proposed Substitute and Seller Substituted would mean the seller set
this status, Buyer Proposed Substitute would mean the buyer did.
YS: I cannot understand the structure of use case of Order
document with business process. Plese teach me when you come to Tokyo.
(2)There is no ABIE referred from
SellerProposedSubstitutionLineItem (ASBIE).
(3)There is no ABIE referred from BuyerProposedSubstitutionLineItem
(ASBIE).
Once again, these are qualified ASBIEs (both re-use Line Item as the
ABIE)
2.5 OrderReference
(1)Is DocumentDocumentStatusCode mistaken? The characters ‘Document’
are doubled.
(2)Is IssueIssueDateDate mistaken? The characters ‘Issue’ and ‘Date’
are doubled.
yes this is a mistake - the formula has not be refreshed (i think this
is a result of swapping between open office and excel). In the schemas
the names are correct (Document StatusCode and IssueDate).
An important point to mention is that whilst we tried very hard to get
the full naming formulae into the sp[readsheets - they are sometimes
too sophisticated for spreadsheet formaluaes. In some cases (this is
not the reason in this case) the UBL Name is not exactly correct.
These are what Chee-Kai has identified and will be fixed in the 1.1
spreadsheets. As an example they often involve the use of GUID in the
names. If in doubt, the element names in the schemas are the normative
form of the UBL Name. They differ because the program used to create
the scehmas is better able to implement to complete naming rules and
did not rely on the spreadsheet given names.
YS: I think that UBL TC had better check the spreadsheets again
especially at important items (e.g. UBL name, Definition). Because our
users of UBL business documents are usually look at spreadsheet for
UBL specifications instead of XML Schema.
2.7 Party
(1)I cannot understand MarkCareIndicator. What is C/O in Definition?
C/o is short hand for "care of". This means when a Party is not the
actual Party we mean but this Party is acting as their agent.
(2)I cannot understand
MarkAttentionIndicator. What is FAO in Definition?
FAO is "for attention of". This means we want to explicity
denote this Party is to deal with the matter.
YS: Please teach me how to use MarkCareIndicator and
MarkAttentionIndicator, whe you come to Tokyo.
(3)The Cardinality of following ASBIEs are
‘0..1’. I think that this means nothing or once. But the definition
says ‘one or more’. I think that this is inconsistent.
PartyName
the definition is incorrect - the ASBIE can only appear once (or not at
all). However, within the ABIE referred to, PartyName, there can be
many names.
Address
the definition is incorrect - a party can only have one Address (or not
at all).
Contact
the definition is correct - it says "associates (optionally) the party
with information on the contact" - nothing about 'one or more'.
Language
the definition is incorrect - a party can only have one Language (or
not at all).
2.8PartyTaxSchema
(1)There is no ABIE referred from RegistrationAddress (ASBIE).
It is an Address qualified as being the Registration address.
2.9PaymentMeans
(1)I cannot understand the difference between CardAccount and
CreditAccount.
A Card Account may be a debit or credit account type.
YS: I cannot understand how to use CardAccount and
CreditAccount. Please teach me when you come to Tokyo with examples.
(2)There is no ABIE referred from
PayerFinancialAccount (ASBIE).
It is a Financial Account qualified as being that if the Payer
(3)There is no ABIE referred from
PayeeFinancialAccount (ASBIE).
It is a Financial Account qualified as being that if the Payee
2.10PaymentTerms
(1) There is no ABIE referred from SettlementPeriod (ASBIE).
It is a Period qualified as being that for the Settlement
2.11ReceiptLine
(1)What is THU (Transport Handling Unit) in Definition?
The terms comes from the UN/CEFACT Transport TBG (I think). It
is the logistical equivalent of an Stock Keeping Unit (SKU) for
Inventory. That is, the smallest unit that can be shipped around.
YS: I understood. Thank you.
(2)What is OrderItemIdentification?
It is a reference to the item (or items) originally ordered for which
we are acknowledging receipt.
(3)There is no ABIE referred from
OrderItemIdentification (ASBIE).
It is an Item Identification qualified as being what was Ordered. (Note
that this is not OrderItemIdentification but OrderedItemIdentification).
2.12SecondaryHazard
(1) Is Definition of Extension (BBIE) correct? The Definition says
‘identifier’.
The definition could be better - it is not an identifier. I
would propose "additional information regarding the hazardous
substance. Can be used to specify information such as the type of
regulatory requirements that apply to a description."
YS: I agree. Thank you.
2.13SellerParty
(1)I cannot clearly understand BuyerAssignedAccountID. The definition
says ‘to allow integration with a back office system’. Is there any
relation between AccountID and back office system?
(2) I cannot clearly understand SellerAssignedAccountID.
What we mean here is that each party may have their own way of
identifiying their trading partners within their internal systems. For
exmaple, a creditor's system may give the buyer a code number to use
for their suppliers (and vice versa). often these appear in trading
documents. They are commonly used when two trading parties may have
several different dealings with each other and require an allocation to
different parts of the business.
The BuyerAssignedAccountID is the way the Buyer wants to identifier the
Seller. The SellerAssignedAccountId is what the Seller wants to be
identified by.
YS: I misunderstood that these accounts are Bank account number.
Is the term 'Account' suitable in this usage?
2.14Shipment
(1)This ABIE is not referred by any other ASBIE as name.
I think it is in Ordered Shipment.
(2)There is no ABIE referred from
TransportContract (ASBIE).
It is a Contract qualified as being that for the Transport of the goods.
2.15ShipmentStage
(1)There is no ABIE referred from CarrierParty (ASBIE).
It is a Party qualified as being the Carrier of the goods.
(2)There is no ABIE referred from
TransitPeriod (ASBIE).
It is a Period qualified as being that for the Transit of the goods.
2.16TransportEquipment
(1)The Definition of FullnessIndicationCode says ‘a piece of transport
equipment is full, empty or partially full’. What is the meaning if the
transport equipment is full?
Transport Equipment is almost always a shipping container. So
this means a full, empty or partially full container.
YS: I understood. So, don't you think that the name
'TransportEquipment' had better to be changed to 'ShippingContainer'?
2.17TransportHandlingUnit
(1)The Definition of both HandlingUnitDespatchLine and
ReceivedHandlingUnitReceiptLine is same. Is this mistaken?
yes. the ReceivedHandlingUnitReceiptLine should say "associates
the Transport Handling Unit with one or more receipt lines on a receipt
advice."
YS: I understood. Thank you.
(2)There is no ABIE referred from
HandlingUnitDespatchLine (ASBIE).
It is a Despatch Line qualified as being that for the Handling Unit
(3)There is no ABIE referred from
ActualPackage (ASBIE).
It is a Package qualified as being that the Actual package. That is
the package(s) the receipient will see when they open the transport
handling unit.
(4)There is no ABIE referred from
ReceivedHandlingUnitReceiptLine (ASBIE).
It is a Receipt Line of the Handling Unit being received.
3. Others
3.1Business process regarding DespatchAdvice and ReceiptAdvice
I cannot clearly understand the business process of DespatchAdvice and
ReceiptAdvice. What is Delivery Recipient concretely?
Normally this would be the buyer, but we acknowledge that the
party accepting receipt of the goods may not be the Buyer. So we
called this the Delivery Recipient. Perhaps "buyer (or their agent)"
may have been clearer.
YS: I understood. Thank you.
(3)There is no ABIE referred from
ShippingContract (ASBIE).
It is a Contract qualified as being that for the Shipping of the goods.
Yukinori Saito wrote:
Dear members of UBL TC,
I have translated the latter half part of UBL Reusable V1.0 into Japanese
Language.
I have sent the translated UBL Reusable V1.0 spread sheet to you at the
previous e-mail.
In the procedure of translation, I have had many questions and comments
regarding BIEs in UBL Reusables (the latter half part).
The questions and comments are improved by some comments presented by some
JPLSC members.
The attached document is the questions and comments written in English..
We are happy if you will reply to these questions and comments.
Best Regards,
Yukinori Saito
-------------------------------------------
Yukinori Saito
Fuji Electric Information Service Co., Ltd. (FIS)
e-mail: saito-yukinori@fujielectric.co.jp
Tel: +81-3-5435-7333 Fax: +81-3-5435-7513
-------------------------------------------
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