Next in thread →
Next in month →
AW: [bdx] Proposal for a TC recharter
Roger,
You explicitly say that adding the term 'web services'
is to extend rather than limit the concept of data exchange. However this is (at
least from a layman's perspective) precisely not the impression it is conveying.
In my ears "web services interoperability" is about connecting web services (or
even Web Services), whereas the very point of what we are doing is we don't care
about *what* we are interconnecting (or so I thought). Just my two
cents.
Susanne
Von: Roger Bass
[mailto:]
Gesendet: Montag, 5. März 2012
19:05
An: 'Mikkel Hippe Brun'; 'Kenneth Bengtsson'
Cc:
Wigard, Susanne (IT.NRW); 'Tim McGrath'; ; 'Jens Jakob
Andersen'
Betreff: RE: [bdx] Proposal for a TC
recharter
Kenneth,
Mikkel,
I
won?t belabor the point much further, but it seems to me the already agreed
scope here is more than just ?messaging service interoperability?. SML/P
(and indeed CPPA) are about interoperability at the level of business
capabilities to exchange very specific types of data (invoice, order? and
doubtless other types in the eCODEX domain). Kenneth, you didn?t comment
specifically on leaving out ?web services?.
I
think Mikkel?s points emphasizing the ?lightweight? requirement are well made,
and I?m certainly not arguing for any particular heavyweight standard from the
Web Services domain. I see it as a broader issue. Rightly or
wrongly, leaving out ?web services? contributes, I think, to a continuing
impression that the TC is reluctant to even consider leveraging or aligning
with the fairly substantial related efforts to date elsewhere, in particular
around web services (lower case!) and SOA more broadly, and even if that?s a
longer term goal.
If
I?m the only person thinking like this on ?web services? then I?ll drop the
point, but I?d be interested in hearing specific arguments for excluding
it.
Best,
Roger
From:
[mailto:] On Behalf Of
Mikkel Hippe Brun
Sent: Monday, March 05, 2012 8:42
AM
To: Kenneth Bengtsson
Cc: Roger Bass;
; Tim McGrath; ; Jens Jakob
Andersen
Subject: Re: [bdx] Proposal for a TC
recharter
I am very happy with the proposed change.
Regards
Mikkel
On Mon, Mar 5, 2012 at 5:03 PM, Kenneth Bengtsson <>
wrote:
Dear
all
Good idea with
the Wiki. I will follow up on that.
I'm also in
agreement with Mikkel's comments and in general I support the proposed
changes. However I also think that "interoperability" is an important aspect
of the work of the TC and shouldn't be removed entirely. One could say that to
"exchange data between domains" interoperability is implicit, but I still
think we could benefit from emphasizing it. I would be fine
with:
Proposed:
The purpose
of the TC is therefore to define the specifications of
a lightweight
and federated
messaging and trust infrastructure for reliable data
exchange and messaging services interoperability between
domains.
Best
regards,
Kenneth
From:
Roger Bass <>
Date: Sun, 4 Mar 2012
21:19:42 -0800
To: Mikkel Hippe Brun <>,
<>
Cc: Kenneth Bengtsson
<>, Tim McGrath <>, <>, Jens Jakob Andersen <>
Subject:
RE: [bdx] Proposal for a TC recharter
Kenneth,
Susanne, Mikkel et al,
My
apologies too, belatedly, for missing the last meeting ? I look forward to the
next one. Given the ongoing discussions and emails about potential
edits, I wonder if it would be helpful to leverage the OASIS wiki
infrastructure for this charter discussion? Keeping track via of
proposed changes all the emails is challenging. I did just verify that
no OASIS wiki has yet been set up for BDX. Kenneth, as the new chair,
would you be able to request this from the TC-Admin? Ideally perhaps,
the wiki might show the draft charter as you originally submitted it, Kenneth,
with each subsequent change noted separately.
As
to the specifics of Mikkel?s proposals: adding ?lightweight? and ?reliable?
seem good to me.
I?m
less comfortable with removing ?web services interoperability?. I agree
we shouldn?t limit ourselves to ?Web Services? in the formal, capitalized
sense. However, as originally written here, I think the sense of adding
that term is to *extend* rather than *limit* the concept of data
exchange. Using lower case, I think, also implies we?re not limiting
this to the WS-* stack (RESTful web services etc included, for example).
And while I?m aware that OASIS has taken on the WS-I work, my understanding is
that that was more narrowly scoped, and is now in maintenance mode. ?Web
services? is also an important, descriptive term used for much related work in
this domain, and I think it?s helpful to point that out here.
Best
regards,
Roger
From: [mailto:] On Behalf Of Mikkel
Hippe Brun
Sent: Friday, March 02, 2012 1:04 AM
To:
Cc: ; ; ;
Subject: Re: [bdx] Proposal for a TC
recharter
Thank you for this clarification Susanne. I am very exited
about the prospect of getting new resources into the TC. I have re-read the
proposed charter multiple times and I can see where you are coming from and
that you really intend to make the TC very operational.
The only thing I miss from the old charter is the emphasis on
the resulting infrastructure in itself being lightweight. It also follows from
the infrastructure being federated, but the critical part is that any
centralized infrastructure components have as little footprint as possible.
The more we can piggybag on existing infrastructure the better. Such a framing
would also scope discussions about service discovery and addressing
specifications like UDDI and ebXML RegRep.
I would then sugges the following change to the proposed
charter:
Original:
The purpose of the TC is therefore to define the
specifications of a federated messaging and trust infrastructure for data
exchange and web services interoperability between
domains.
Proposed:
The purpose of the TC is therefore to define the
specifications of a lightweight
and federated
messaging and trust infrastructure for reliable data exchange between
domains.
I have taken out the "web services interoperability" because
this is covered by other OASIS TC's and I dont think that we should limit
ourselvs to web services (in the classical sence). The old charter
mentioned "messaging service standards" and I think this term covers the
intention better.
All the
best
Mikkel
On Thu, Mar 1, 2012 at 11:01 PM, <> wrote:
Dear
all,
First let me apologize
for failing to join the telco. I'll have more comments when I get to see the
minutes - for now let me just emphasize that indeed the intention of
broadening the scope goes anlong with the goal to add resources to the
TC, in particular from the LSP project that I'm working with, e-CODEX,
and connected to activities in the context of creating a common transport
infrastructure for the ongoing and future LSPs. So it's not about disreagrding
the PEPPOL work, but quite to the contrary about continuning it into new
projects and domains.
Regards
Susanne
____________________________________
Susanne Wigard
Phone +49-211-9449-6742
Mobile
+49
1735260181
Von: [mailto:] Im Auftrag von Mikkel
Hippe Brun
Gesendet: Donnerstag, 1. März 2012 22:28
An:
Kenneth Bengtsson
Cc: Tim McGrath; ; Jens Jakob
Andersen
Betreff: Re: [bdx] Proposal for a TC
recharter
Thank you for the clarification Kenneth. This sounds very
good and I look forward to the continued discussion and the next
meeting.
Regards / Hilsen
Mikkel
Cell: +45
31189102
Mail:
Den 01/03/2012 kl. 21.40 skrev Kenneth Bengtsson <>:
Dear Tim and Mikkel
I agree with your comments, and it was as such also the
intention with the proposed charter to reflect these viewpoints. I'm sure
the wording can be improved:
In the statement of purpose it says that TC specifications
should be...
"...wherever and to the extent possible, based on
profiles of existing standards from OASIS and elsewhere that are
widely-used and proven, or otherwise seen to be generally
applicable.".
The intended meaning of this is, exactly as both of you
commented: To focus on technologies that already exist and can be put into
immediate use in the work of the TC.
Also in the statement of purpose:
"In certain areas the work will therefore initially
be centered on the work of these LSPs (notably on SMLP around identity
and service discovery, addressing and profiling), and will also consider
other approaches and related specifications (e.g. DNS, ebXML CPA, UDDI,
ebXML RegRep, WS-Discovery)...".
The intended meaning here is to say: We will leverage the
work already done by PEPPOL and other LSPs - this is our starting point.
However, if along the way we accept specific requirements or if we see
that our work can benefit from it, then we shouldn't by default disregard
other technologies. We have a solid starting point with the work already
produced by the LSPs and it is from there that we progress. However we
shouldn't progress wearing blinkers.
In the scope of work is specifically mentioned that the
specifications from PEPPOL (namely SML, SMP, START and LIME) will have
their home in the TC. The SML/SMP technology are the foundation for
discovery, whereas START and LIME may have more PEPPOL-specific uses. I'd
like to stress again that it is not the intention to disregard the work
already produced.
I'm sure that the wordings in the proposed charter can be
improved to better reflect the intended meaning. There is no pride in
ownership, so please feel free to make all the suggestions for improvement
that you like! At yesterday's meeting we agreed to postpone the vote for
the recharter until March 14 to allow for comments and specific
proposals.
With regards to the "speed with which the TC can work":
Mike made the comment yesterday that broadening the scope of the TC means
that more work has to be produced, and that adding more resources is by no
means a guarantee that work will progress any faster. This is a valid
comment and it is in most cases true. However, in our specific case it is
a specific objective with the recharter to make the TC a platform for
producing specifications for an ongoing convergence of the LSPs respective
eDelivery technologies. A widening of the scope will therefore enable the
LSPs to add resources to the TC and to take a leading role. As the LSPs
are also working with milestones and deadlines I do in fact believe that
the proposed recharter will make the TC gain momentum rather than loosing
it.
Joao volunteered yesterday to make a suggestion to the
proposed charter for clarifying/underlining the role and significance of
the LSPs (and the LSP convergence process) in the TC.
Best regards,
Kenneth
From:
Tim McGrath
<>
Date:
Wed, 29 Feb 2012 22:49:15 +0800
To: "" <>
Cc: Mikkel Hippe
Brun <>, Kenneth Bengtsson <>, Jens Jakob Andersen <>
Subject: Re: [bdx] Proposal
for a TC recharter
I also have a call conflict for today's call. i support
Mikkel's view on this - the rechartering is a good step forward, but there
is a risk of loosing momentum. We should be capitalizing on the
progress PEPPOL and other LSPs have made in this area. That is, we
should be building on what we have, not what we would like to
see.
On 29/02/12 10:28 PM, Mikkel Hippe Brun wrote:
Dear
all,
I will
unfortunately be in transit during todays call due to a delayed
flight.
I do
support the change to the TC's charter if it means wider support to the
TC's work from the other large scale pilots. I do however have concerns
about the widening of the scope as it will impact the speed with which the
TC can work (Mike's argument).
One
important criteria that is fundamental for the large scale pilots
mentioned in the charter is that there is very little willingness to
establish and fund more than the most essential shared infrastructure
components. It is therefore in my opinion very important that the
technologies that the TC explores for service discovery and addressing
piggybacks on existing Internet infrastructure like
DNS.
I
don?t find UDDI or ebXML RegRep to be operational and scalable for large
scale infrastructures. We may as a TC and individuals find the standards
behind UDDI or
ebXML RegRep to be appropriate, but the reference implementations are not
battle proven for large scale use. And it is my very strong opinion that
the TC should focus on technologies that are battle proven and can be put
into use immediately.
Finally - I would like to
step down as chair for the TC, but I would like to continue as TC
member.
Best
regards
Mikkel
On Tuesday, February 21, 2012, Kenneth Bengtsson
wrote:
Hi Jens Jakob
I very much agree with you that this
is an important design goal and
objective for a number of applications
(PEPPOL for example). At the same
time I also believe we must
acknowledge that other applications can have
different requirements and
implementation architectures.
One of the important reasons for the
proposed recharter is to allow for a
broader and more general
application of the BDX specifications. This
doesn't mean that we in
PEPPOL will accept to have specific protocol
requirements imposed on
the "final leg" between gateway and enduser, I
strongly agree with you
on this. What it means is that we see an advantage
in opening up the
possible use cases for BDX, and not let the requirements
of one project
stand in the way of a more broad adoption.
Best
regards,
Kenneth
On 2/20/12 8:15 AM, "Jens Jakob
Andersen" <> wrote:
>Hi
Kenneth
>
>Thank you for the clarifications.
>
>I
still cant see in the specs, that is is a _must_, that the protocols
to
>be used between gateways must be agnostic to whatever is used on
the
>first & last legs.
>
>Some of the "GW to GW"
protocols I have seen demonstrated, has many
>features that can only
be usefull, when the same family of protocol is
>used
end-2-end.
>
>The original design-goal of BDX was to deliver a
"meta-protocol" to be
>used between gateways - to interconnect
different domains. And supporting
>many different
transport-protocols below.
>
>From my (fast fading viewpoint
as I am leaving the TC), these
>design-goals should be kept as the
TC's design-goals.
>
>Best regards
>
>Jens
Jakob
>
>-----Oprindelig meddelelse-----
>Fra: Kenneth
Bengtsson [mailto:]
>Sendt: 13. februar
2012 15:58
>Til: Jens Jakob Andersen; Tim McGrath
>Cc:
>Emne: Re: SV: [bdx] SV:
Proposal for a TC recharter
>
>Hi Jens Jakob
>
>As
Tim already mentioned, the 4-corner model is described already in
the
>first paragraph.
>
>With regards to "connecting
islands":
>
>In the first paragraph is stated that BDX
describes a model "where two
>entities exchange business documents
in a secure and reliable way through
>the use of gateways". If we
can agree that it is in the definition of a
>gateway that it has two
sides, then it is in logic that the two entities
>exchanging
business documents must each connect to their respective
>gateways,
and that the gateways must connect to one another. Then you
>have
the first, the last, and the middle "leg" of the transaction. If
you
>read the second and third paragraph of the statement of purpose
and
>replace "domain" with "island", then I think you will agree
that it is
>actually in the proposed purpose statement to "connect
different islands
>of networks".
>It is my understanding that
the term "island" is mainly used in
>procurement jargon, why we have
used the more generic term "domain" to
>describe exactly the same.
This is also to signal that the potential use
>of BDX goes beyond
procurement and e-commerce business documents - BDX
>can be used for
any type of electronic business document.
>
>Best
regards,
>
>Kenneth
>
>
>On 2/13/12 9:44 AM,
"Jens Jakob Andersen" <> wrote:
>
>>Hi
Tim
>>
>>Thank you for the
clarification.
>>
>>That is half of
it.
>>
>>What I am looking for is the other part of the
4-corner model, that
>>different protocols can be used on the
"first leg" and "last leg" and
>>the "inbetween" part can be a
standardized "meta-protocol" such as
>>START - open for mapping
to "any" actual protocol.
>>
>>This is the core of the
idea of START /and BusDox and BDX/ - that the
>>challenge is to
"connect different islands of networks".
>>
>>The
acid-test for any change should (IMHO) be: "Can it deliver
the
>>value mentioned, in a setup with different
protols/implementations on
>>the first and last
leg".
>>
>>Best regards
>>
>>Jens
Jakob
>>
>>-----Oprindelig
meddelelse-----
>>Fra: Tim McGrath [mailto:]
>>Sendt:
13. februar 2012 11:22
>>Til: Jens Jakob Andersen
>>Cc:
Kenneth Bengtsson;
>>Emne: Re: [bdx] SV:
Proposal for a TC recharter
>>
>>it is in the statement
of purpose.
>>> The BDX standard will describe an architecture
(or sets of reference
>>>architectures) where two entities
exchange bu
--
Best regards,
Mikkel
Mikkel Hippe
Brun
Chief Strategy Officer, Cofounder
Voice: +45 3118 9102
Skype:
hippebrun
Twitter: @hippebrun @tradeshift
Mail:
Web: http://tradeshift.com
-- INVOICING HAS NEVER BEEN
EASIER
--
Next in thread →
Next in month →