OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: Fantasies - Vote for flying pigs

Looking at it a different way;

If partner A uses SAP and sends from SAP using their SAP to ANSI/XML form
transform they would be target a standard rendering.  If partner B uses
Baan and has an ANSI/XML to Baan transform script then to interface with
partner A they only need to and from scripts between ANSI/XML.  (ANSI/XML
of course being an ebXML compliant rendering of an ANSI document)

N in these instances would not be trading partners but the number of
standard DTD/schemas a party, or application, would map to.  However, I
guess the flaw in this thinking is that there are millions of standards out
there.  Which means we've gone full circle :-)

However, such a repository approach would let the market dictate which
standards would be the preeminent standard in a given field.

Have a nice weekend,
John Motley

"Hayes, Brian" <Brian.Hayes@Commerceone.com> on 04/06/2001 06:19:52 PM

To:   Philip Goatly <philip.goatly@bolero.net>, John.Motley@log-net.com,
      "'William J. Kammerer'" <wkammerer@foresightcorp.com>
cc:   'ebXML Core' <ebxml-core@lists.ebxml.org>, Peter Guldentops

Subject:  RE: Fantasies - Vote for flying pigs

The observation:
>  For N partners that would make potentially N*(N-1)
> transformations/translations
used to bother me a bit.  Until I asked the question, what we doing to
this in EDI?

Let's see, I have a translator between my newtwork and my backend system.
also have N-1 trading partners to deal with... Worse case is N-1

So the way I see it, I would hope that we are not worse off than we were
before and I believe that we are better off.


> -----Original Message-----
> From: Philip Goatly [mailto:philip.goatly@bolero.net]
> Sent: Thursday, April 05, 2001 1:53 AM
> To: John.Motley@log-net.com; Probert, Sue
> Cc: 'William J. Kammerer'; 'ebXML Core'; Peter Guldentops
> Subject: Re: Fantasies - Vote for flying pigs
> Hi there,
>   I see what you are saying, but when there are more than 2
> trading partners
> involved  ........
> The transformatinos might become exponential i.e
>  For N partners that would make potentially N*(N-1)
> transformations/translations
> Unless of course all the partners use exactly the same format - but in
> chains the Banks might have to deal with all possible
> versions of an Invoice that any 2 partners could think up,
> not to mention
> the ocean carriers whonwill deal with any product from
> ball-bearings to Coal
> to clothing?
> Please could someone explain how the standard is to be enforced ?
> Cheers, Phil.
> ----- Original Message -----
> From: <John.Motley@log-net.com>
> To: "Probert, Sue" <Sue.Probert@commerceone.com>
> Cc: "'William J. Kammerer'" <wkammerer@foresightcorp.com>;
> "'ebXML Core'"
> <ebxml-core@lists.ebxml.org>
> Sent: Tuesday, April 03, 2001 11:25 PM
> Subject: RE: Fantasies - Vote for flying pigs
> >
> >
> >
> > If a repository held both the standard DTD/schema, built from core
> > components, and a trading partners XSLT scripts to
> transform to/from the
> > standard to their form there would be a fairly nice path.
> Such that a
> > second trading partner need only develop a transform script
> to get to the
> > standard and then use the other partners "registered
> script" to get to
> that
> > version.  Or serve it up in the standardized form for the
> other party to
> > process.  Loss of information from one partner having
> higher levels of
> > granualarity than the other are unavoidable.
> >
> > Regards,
> > John Motley
> >
> >

To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC