Hi All,
After meeting with Ken this week in
Barcelona, I wanted to point out the work that Philip and I have done over
the past 3 years in scoping and delivering the PEPPOL Directory Business
Card, which is now live at the address below...
Currently PEPPOL Directory is only supported
by the following SMPs UK NHS (Invinet), BRZ, IBM, but we have committments
that Difi will be connecting ELMA in the short, term as well as the Italian
Intercenter SMP.
With the 150k French Endpoints soon
to arrive to the PEPPOL SML, we hope they will soon adopt PEPPOL Directory,
and we've also had positive discussions with Australia about boarding their
data.
It may still be some time before I get
full member access on Oasis, so I hope this meas of adding comments is
ok in the meantime
Cheers
Ger
directory.peppol.eu.
https://www.ibm.com/blogs/peppol-by-ibm/peppol-directory-deployment-approved/
with
kind regards
Ger Clancy
Offering Manager eInvoicing & PEPPOL
IBM Watson Customer Engagement
Mobile:+353 86 859 6872
E-mail:
My IBM Homepage: ibm.biz/GerClancy
Chat:ger.clancy72
Find me on:
IBM
Ireland Limited
Registered in Ireland with no.: 16226
Registered Office: IBM House, Shelbourne Road, Ballsbridge, Dublin 4, Ireland
From:
David Goodenough <>
To:
Date:
11/10/2017 18:04
Subject:
Re: [ubl-comment]
Question about the BusinessCard object
Comments inline, not sure how readable this will be, if
you can not tell what I have added please let me know. My mail client handles
text embedded conversations well, but rich text ones (like this one) seem
badly handled.
David
On Tuesday, 10 October 2017 19:57:04 BST JAVEST by Roberto
Cisternino wrote:
Il 10/10/2017 11:09, David Goodenough ha scritto:
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.
I understand your point, but the UBL-BusinessCard is not
only a card, it is primarly a message.
If it primarily a message, what the receiver do with it,
and how would they reply?
I think any UBL business document has a sender and a recipient, as we are
supporting business processes and collaborations so the minimum number
of parties involved is 2, do you agree ?
Why exclude the concept (as defined in its purpose description)
of a broadcast object which can be sent to anyone without tailoring. Such
broadcast objects have a real use in such cases as starting the whole communications
system.
Most UBL documents are requiring both the sender and the recipient parties,
not all... but this is when we must give more freedom to implementers.
If you think that we must give such freedom I could agree, but this means
you think implementers may use the UBL-BusinessCard for storage and not
*only* for exchanging its information.
I see to need to include the recipient data in a broadcast
object.
I like this idea, after all XML databases are a reality, so it could be
that modern portals, yellow pages or business directories will adopt the
UBL-BusinessCard as a direct storage unit on the file system or in a database
blob.
The recipient will be added on the last stage before sending it to other
parties.
How can the recipient be added when downloading it from
a web site or from a QR code printed in a physical directory? Or are you
saying that I would have to fill in all my Party data in order to download
the BusinessCard froma web site? This would an error prone process and
rather defeats one of the driving features of UBL which is to eliminate
duplicate typing. I could not upload my pre-populated BusinessCard because
it would not have a receipient Party in it.
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.
First of all I fix the name that is singular "UBL-DigitalCapability",
my mistake on the previous mail.
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?
BusinessCard should not be mixed with the DigitalCollaboration,
the second one is strictly for configuring EDI systems.
Perhaps not, but it is needed as part of the process of
introducing two businesses to each other, at at least it could be used
to good effect if it were a broadcast object.
I agree the folowing is wrong and needs to be revised asap:
>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.
>The data structures have been derived
from the work of ebXML CPPP, OpenPEPPOL and other directory services initiatives.
It should be:
"The Business Card allows a standardized way of presenting general
trading capability information as well as main company's communication
channels and presentations such as flyers and brochures."
____
The DigitalAgreement part is ok but there is a missing paragraph for the
DigitalCapability document.
Please review this:
2.3.8.3 Digital Capability
The Digital Capability allows a standardized
way of presenting digital trading capability information in a form that
can be published or exchanged with trading partners. The digital
capabilities of business partners are the source for building a Digital
Agreement.
2.3.8.4 Digital Agreement (...I
JUST RENUMBERED THIS...)
Bi-lateral and multi-lateral trading partner
agreements can make use of the standardized Digital Agreement document
used to support business parties agreeing on a set of digital processes,
terms and conditions.
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.
It is true that in the specification there is a missing
graph overview for the BusinessCard document, while the graph for the Digital
Agreement and Digital Capability is correct.
The BusinessCard is more generic and related to the common practice of
exchanging business information in different domains:
- Marketing and communication (Web sites, social channels, ...)
- Financial Information (e.g. When I want communicate my new Banking account
to my partners)
- General information (Address, Tax IDs, so on...)
- Trading capabilities (What the company do in textual form)
Of course it is intended also to introduce a company to another, but it
is not specific for digital processes.
The DigitalCapability is specific for service providers, EDI partners,
and of course for building digital agreements.
The communication can be started with a plain BusinessCard or directly
using a DigitalCapability if the purpose is to start a digital collaboration.
Not at all sure this makes sense. The whole point of UBL
is to make as many parts of business interaction digital, it is the definition
of how that digital interaction should occur and how the dataflows should
be structured. Why is UBL defining a non-digital object? The useful thing
to do is to use the Business Card concept and extend it into the digital
world and the concept is to broadcast information.
David
David
On Tuesday, 10 October 2017 00:11:21 BST JAVEST by Roberto
Cisternino wrote:
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:-
>>>
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 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!
David
Let me know if you need further support. Best regards
Roberto Cisternino UBL ITLSC chair
