RE: Trading Partner Logical Identification based on EDIFACT or X12qualifiers

[mwsachs@us.ibm.com]

Dick,

I think we both believe that a repository interface can be useful but its
use should not be mandatory.

However if ebXML were to define a programmatic API to the repository and
make it a mandatory part of the ebXML-defined repository, that would
benefit software providers by assuring that the same software could be used
with all repository implementations.

Regards,
Marty

*************************************************************************************

IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com
*************************************************************************************



"Dick Brooks" <dick@8760.com> on 08/16/2000 10:56:00 AM

Please respond to <dick@8760.com>

To:   Martin W Sachs/Watson/IBM@IBMUS, "David RR Webber"
      <Gnosis_@compuserve.com>
cc:   "ebXML Transport \(E-mail\)" <ebXML-Transport@lists.ebxml.org>,
      "David Burdett" <david.burdett@commerceone.com>
Subject:  RE: Trading Partner Logical Identification based on EDIFACT or X1
      2qualifiers



Marty

I'm not debating the point that a repository interface CAN be useful (in
fact I believe it could be useful in certain cases). My position is that a
programmatic API to a repository SHOULD NOT BE MANDATORY within ebXML.


Dick Brooks
Group 8760
110 12th Street North
Birmingham, AL 35203
dick@8760.com
205-250-8053
Fax: 205-250-8057
http://www.8760.com/

InsideAgent - Empowering e-commerce solutions

> -----Original Message-----
> From: mwsachs@us.ibm.com [mailto:mwsachs@us.ibm.com]
> Sent: Wednesday, August 16, 2000 8:39 AM
> To: David RR Webber
> Cc: INTERNET:dick@8760.com; ebXML Transport (E-mail); David Burdett
> Subject: RE: Trading Partner Logical Identification based on EDIFACT or
> X1 2qualifiers
>
>
> Dick,
>
> Where I come from, web site A contacting web site B on the side can add
> minutes if site  B is up at all.  (Today, for example, the ebXML web site
> appears to be down).  So a few tenths of a second implies some
> super-robust
> repository and communications paths.  Is this realistic?
>
> It also seems to me that the decision to check partner ID validity or
> security should be an application decision, not a unilateral decision on
> the part of the messaging layer.
>
> Regards,
> Marty
>
> ******************************************************************
> *******************
>
> IBM T. J. Watson Research Center
> P. O. B. 704
> Yorktown Hts, NY 10598
> 914-784-7287;  IBM tie line 863-7287
> Notes address:  Martin W Sachs/Watson/IBM
> Internet address:  mwsachs @ us.ibm.com
> ******************************************************************
> *******************
>
>
>
> David RR Webber <Gnosis_@compuserve.com>@compuserve.com> on 08/15/2000
> 07:32:06 PM
>
> To:   "INTERNET:dick@8760.com" <dick@8760.com>
> cc:   "ebXML Transport (E-mail)" <ebXML-Transport@lists.ebxml.org>, David
>       Burdett <david.burdett@commerceone.com>
> Subject:  RE: Trading Partner Logical Identification based on
> EDIFACT or X1
>       2qualifiers
>
>
>
> Message text written by INTERNET:dick@8760.com
> >
> ebXML should be solution for all the above and we cannot mandate
> the use of
> an ebXML specified repository, particularly in the interactive/thin
client
> case.
>
> I also believe the more we can explicitly and unambiguously define in the
> specs the greater our chances for success meeting the interoperability
> challenge. I DO recommend that we define a core set of "standard" values
> for
> the PartyId/context in order to ensure a "lowest common denominator",
PLUS
> add an extension capability for those who wish to engage in a mutual
> consent
> arrangement. I DON'T believe an API for regrep/TA will circumvent the
need
> to define a standard set of options for PartyId/context, especially in
the
> case of an interactive/thin client. I DO believe we need an API for
> regrep/TA for those implementations that can benefit from having an ebXML
> compliant repository available.
> <<<<<<<<<<<<<
>
>
> Dick - once again my favourite phrase de jour - EXACTLY.
>
> People need to think of the Repository of NOT being some behemoth in the
> sky.
>
> It's our job over the next few months leading up to Tokyo to show
> that this
> can
> be an extremely light weight and elegant control mechanism.
>
> Notice that if you are transfering across the internet you already have
> connectivity - so there really is NO excuse for spending a few extra
10ths
> of seconds making sure you have a robust interchange.  This can be
> done with nothing more than JavaScript at the client side simplest case.
>
> PLUS - the extra business security you gain is more than worth the
effort.
>
> In the old paper world we call ahead to check someones FAX #, and then
> when the FAX goes thru, we get a confirmation, and the FAX itself carries
> the
> sender/receiver #'s.
>
> For the transport layer to check into a repository reference to
> cross-check
> is part of the interchange is a sound business practice approach.
> We do this right now with HTML with DNS, and other Apache / IIS related
> control/reference mechanisms.
>
> I'm definately looking at implementation mechanisms that are simple and
> effective here to meet the business needs you identify.
>
> Of course there will be the 10% of people who want the behemoth solution
-
> so
> we will support that too.   Have Microsoft said anything about, or have
> they been
> asked about, supporting ebXML interchange headers in BizTalk BTW?
>
> I'm sure I'll get a chance to ask them at XMLWorld in Boston next
> month....
>
> Thanks, DW.
>
>
>