Hello Gerald,
your inputs are most welcome.
I remember that the PEPPOL Directory Business Card was a source
for designing both the UBL-BusinessCard and the
UBL-DigitalCapability.
Some time ago together Tim McGrath the UBL TC decided to separate
the generic BusinessCard from the DigitalCapability messager,
because their mission is quite different even if there are also
many common things.
The UBL-BusinessCard holds only trading capabilities and other
Party's info, while the DigitalCapability is strictly used for
building Digital Agreements and setup digital processes.
Many UBL documents are representing well known paper-based
documents, while others are strictly designed for electronic
processing.
That's why the choice to separate these documents.
I will be happy to compare the actual PEPPOL Directory Business
Card version with these UBL messages.
Thank you
Roberto
Il 11/10/2017 18:54, Gerard Clancy ha scritto:
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
