OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [ubl-comment] Question about the BusinessCard object

Hello David,
sorry for waiting so long before providing an answer, I was unable to work fro a while...
please find below my answers:

Il 29/09/2017 16:26, David Goodenough ha scritto:

The business card (as in a piece of card printed with contact details)

is generally a mass produced object, handed out to whoever wants one

with no tailoring to the receiver. It is entirely one-sided, i.e. it

only contains the details of one business/person/organization. Other

sources of similar information would be the headed note paper and

trade or postal directories.

Correct, this reason the UBL BusinessCard is not intended for instructing EDI / B2B systems.
Inside it you can provide Business capabilities in general but not Digital capabilities.
The Business Card is intended as a standard electronic version of the paper one, that can be also used for exchanging data between business directories or simple yellow pages systems, accounting or banking systems.

In order to start a UBL conversation it is necessary for the initiating

party to obtain the Party details of the receiving party, but there seems

to be no high level object that can be send just describing one Party.

These might be printed as QR codes on real business cards or headed

notepaper, or made available for download on a web site.


Once you have the partner Party details then the DigitalCapabilities

and DigitalAgreement conversation can happen, and these can also be

used to update Party information should the need arise.

The UBL DigitalCapabilities are the document you need, this is exactly designed to exchange digital capabilities such as plain old EDI or new XML capabilities.


So my question is why the BusinessCard has a mandatory ReceiverParty

in it, and why it does not have a DigitalCollaboration object? I

am here looking for a rational or definition objectives. It was

presumably added for a good reason/purpose, is that documented anywhere?


The Recipient is mandatory because of course the UBL BusinessCard is intended to be exchanged (e.g. to a provider, bank, partner, ...)
In case the Recipient acts on behalf of another party you can use the BusinessParty information accordingly.

The UBL 2.2 Draft says:-


>>> Business Card

The Business Card allows a standardized way of presenting digital trading

capability information in a form that can be published or exchanged with

trading partners.

Yes, this seems to be uncorrect, I would remove the term "digital" in the beginning.
The only way to describe digital trading capabilities within the UBL BusinessCard is by using textual description.


The data structures have been derived from the work of ebXML CPPP, OpenPEPPOL

and other directory services initiatives.


Correct, but this should be correlated to the UBL DigitalCapabilities document.


It seems to me that is fails on two counts given this definition, firstly

the lack of DigitalCollaboration object which would enable the presentation

of digital trading capabilities, and secondly that it can not be published

to the world, it can only be exchanged with a trading partner, which should

not be necessary as if they are already UBL trading partners both sides must

already have the Party details for the other and the BusinessCard object

makes no provision for update, DigitalCapabilities/DigitalAgreement does.

Digital trading capabilities are described in terms of processes, collaborations and transactions.
You must traverse the DigitalProcess information aggregate.


Or to put it another way, what is the high level object that is

used by a Party to broadcast connection information so that others

may request communications with it? I am rather hoping that this

is not a piece of paper!



Let me know if you need further support.

Best regards

Roberto Cisternino

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]