[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ubl-comment] Question about the BusinessCard object
Roberto,
Thank you for your reply. But I still do not understand.
You say that the Business Card is intended as the electronic version of the paper equivalent, but then later you say that the recipient is required. You have a basic bootstrap problem here. How do you get the receipient Party data? Surely if the Business Card followed its paper equivalent then it would be destination agnostic. And removing the recipient in no way stops it being forwarded. You already have the separation between the sender and the business parties.
You say "The recipient is mandatory ... because it is intended to be exchanged". Yes quite often when you hand out business cards you get one back, but not always and the cards that are handed over are not marked for the recipient in any way. The same goes for directories, they do not contain (or at least they do not have to contain) the recipient's Party data.
When it comes to the digital collaboration object, these are absolutely fundamental to UBL and saying that the DigitalCapabilities object is the way to exchange this misses the point. How can you send the DigitalCapabilities object to someone when you do not know where to send it? It is a recursive unresolvable problem.
There has to be a way to start the communications, and traditionally that is what the business card or directory entry do and they are broadcast objects not directed to a particular recipient.
To my eyes the text in section 2.3.8.2 is exactly correct, and it is the implementation of the BusinessCard object that is wrong. And it as you suggest the second paragraph of section 2.3.8.2 should not be in the description of the BusinessCard but rather in the DigitalCapabilities section, why is it there?
If the BusinessCard object is not designed to start the communications, then what is and why is it not part of UBL? If the BusinessCard object is not there as a broadcast object to start the process, what is its purpose? From your description the process starts at the DigitalCapabilities object, the BusinessCard is useless and thus should be removed from the standard.
David
On Tuesday, 10 October 2017 00:11:21 BST JAVEST by Roberto Cisternino wrote:
Hello David,
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.
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, ...)
The UBL 2.2 Draft says:-
>>> 2.3.8.2 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 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.
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!
David Let me know if you need further support.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]