|
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 $B!F(BID$B!G(B and $B!F(BCode$B!G(B.
(Question)
There are many BIEs of $B!F(BID$B!G(B and $B!F(BCode$B!G(B 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$B!G(Bt have associated ABIE.
Many
ASBIEs have the associated ABIEs in Reusable BIEs. But some ASBIEs don$B!G(Bt have
associated ABIEs. I don$B!G(Bt understand this reason. Is this bug or
something? and
1.5 Some ABIEs don$B!G(Bt have associated ASBIE.
Some
ABIEs are not referred by other ABIEs via ASBIE. To say another word, some
ABIEs don$B!G(Bt 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 $B!F(Bcustomer$B!G(B. This word should be changed to
$B!F(Bseller party$B!G(B. The word $B!F(Bcustomer$B!G(B is not used at any other definitions. And
the word $B!F(Bcustomer$B!G(B 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
$B!F(Brecall$B!G(B. Is $B!F(Brecall$B!G(B same to $B!F(Bcancel$B!G(B? If so, don$B!G(Bt you think the word had
better to be changed to $B!F(Bcancel$B!G(B?
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 $B!F(BDocument$B!G(B are doubled.
(2)Is IssueIssueDateDate
mistaken? The characters $B!F(BIssue$B!G(B and $B!F(BDate$B!G(B 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 $B!F(B0..1$B!G(B. I
think that this means nothing or once. But the definition says $B!F(Bone or more$B!G(B.
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 $B!F(Bidentifier$B!G(B.
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 $B!F(Bto allow integration with a back
office system$B!G(B. 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 $B!F(Ba piece of transport equipment is full, empty or
partially full$B!G(B. 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
|