On Wednesday, 11 October 2017 19:49:42 BST JAVEST by Roberto Cisternino wrote:
Ok,
I comment inline too...
Il 11/10/2017 18:05, David Goodenough ha scritto:
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.
This is an additional requirement, but it looks it is more a requirement for an envelope or a distribution list to be handled by a provider. I think it is not a good idea to bind a set of recipients in a broadcast object, if this is what you intend.
If we remove the 1..1 cardinality from the RecipientParty then the UBL-BusinessCard will be suitable for sharing it on a website or stored into an XML database for direct use.
Excellent!
I may be wrong, but the broadcast aspect seems to be outside of scope for UBL, we can describe it at process level, but we need a use case for that.
I beg to differ, I think it is vital to UBL. There has to be a broadcast mechanism to allow the first non-broadcast interaction to happen. Lets say I am a customer, and I want to buy something from a supplier, and I am an SME with no admin/legal support, so no contracts and no lengthy negotiations. I need to be able to create a DigitalCapability object to send to the supplier so that they can reply with a DigitalAgreement and we can start trading. This should be as simple and painless a process as possible The question is how the data for the supplier's Party information gets into my system ready for inclusion in my DigitalCapabilitiy object. The obvious answer is a business card or similar broadcast object, which I download from their web site (so it is entirely generic). I load it into my system (minimal typing), and tell my system to use that information to build a DigitalCapability object describing my capabilities - probably that I will use email as the transport mechanism and in that I will supply my email address for replies - and then I use that same source of information - which is why I suggested adding the DigitalService object - to direct the request to the right place in the supplier system. This broadcast object does not have to be a UBL BusinessCard, but the requirement looks and feels like a job for a business card, and there is a UBL BusinessCard which is so nearly what is needed and from reading the UBL documentation plays no part in any UBL process.
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?
No, what I mean is that the UBL-BusinessCard can be used in a early stage as a storage unit for holding Party Information without indicating a recipient... later when you need to send it to anyone you will use a software able to edit such UBL document for adding the recipient.
The question here (as above) is how you would know the Party information for the recipient? Are you suggesting that the ability to start a UBL conversation relies on something not defined within UBL but vital to it?
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.
I think in my previous comments I accepted the idea to remove the 1..1 cardinality for the recipient so that this business card will be used into different use case:
- holding party information in a database (without a recipient)
- sharing the party information on a website (without a recipient)
- sending the party information as a message to another party (with the recipient of course).
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, I never asserted that the UBL-Businesscard is not contributing on the digital world... in fact I provided you with several examples... such as the need to update a business party with my new bank coordinated or my new Tax ID.
But there is no process associated with the BusinessCard. If you look at my other thread about changes to Party information surely that has to be done using the DigitalAgreement as it is the only that is versioned. The BusinessCard is not (that I can see). And there needs to be a way for the other interactions to reference the version of the Party data that is relevant to this conversation, but then there is no provision for this anyway.
The upper usage is very important into real business. We do not send business cards only for describing Digital Agreements.
I was not saying it was part of the DigitalAgreement process (it certainly does not appear on the flowchart), I was saying it was a precursor. Somehow the whole digital interchange process has to start, and that would logically be done by a business card like mechanism - i.e. the broadcast of party information. Such a precursor needs to be defined so that the rest of the UBL defined processes can happen, and so that the Party data delivered is the right data for later use. Getting the DigitalService information in there as well would help as well.
The DigitalCapability document is strictly associated to the DigitalAgreement and it represents a precious instrument for service providers.
I agree, I would see it as fundamental also for people using the service peer to peer (my interest). It would also be necessary for solving the Party change problem.
The BusinessCard is more generic. You can think the BusinessCard is partly overlapping with the DigitalCapability, but they can be used into different processes.
We can start using a BusinessCard and never exchange a single digitalcapability and DigitalAgreement, or we can exchange all of them.
Of course
David
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
