Re: The initial ebXML business vocabulary - A call foralistofcandidates

[Erico Azevedo <rational@terra.com.br>]

Hi David / Hi All,

It's certainly difficult to start defining a vocabulary with such huge goals
!
We have brought to the scene (till now) at least the following requirements:

1) Use some "open source": which is great to garantee broad access and
leaverage time-to-market
2) Respect Different industries: each one (with 100% right) believing that
"my case is different, I have specific needs
3) Respect "installed investment base": a miriad of existing industry
standards already exist (with same purposes, but different "implement /
mappings")

Considering all that, if the following sugestions could be of any help:

A) Let's keep things simple and stick to the common interests, modeling
simple business objects/transactions that apply to every industry
B) Let's provide a consistent and standard way of extending dynamically the
ebXML, so that industries investments, specific needs and even regionalities
can be respected, without loss of generality
C) Maybe use the "devide-and-conquer" strategy, creating 3 or 4 integrated
virtual-sub-groups working in the "kernel" (transactions, vocabulary, BO's,
etc) such as an exemple:
    G1) Product/Service description;
    G2) Logistics (pick-up, tracking);
    G3) Deal Conditions (price, availability, delivery time)
    G4) Tech Restrictions (e.g.: minimum level of info / intefaces available
to enter agreement, etc)
    G5) Global / International stuff
D) Work to produce an open source "proof-of-concept" implementation of what
we are talking about

As some of us, including me, work intensely with the mid & small companies,
I believe that most will agree that  XML doesn't mean anything to them
YET!!!
So the approach to reach both small & bigs will be likely "keep simple and
allow standard extentions". The small's won't use much of the extentions but
will be included efectively in the global eletronic market. For the big ones
the "basic approach" will not allways fit (extentions should solve) but
thanks to that "simple" and common "framework" they will be able to go
deeper into business with the small corps in a flexible, cheap and standard
way.


Erico


----- Original Message -----
From: David Lyon <djlyon@one.net.au>
To: Abid Farooqui <farooqui@tampabay.rr.com>; Rémy Marchand
<rm-edi@worldnet.fr>; Cole, Wavell (GXS) <Wavell.Cole@gxs.ge.com>; Mervyn
Colton <Merv@quest.ie>; <ebxml-dev@lists.ebxml.org>
Cc: Rachel Foerster <rachelf@ix.netcom.com>; Gilles Brandel
<Brandel.Gilles@srci.fr>
Sent: Thursday, June 21, 2001 12:27 AM
Subject: Re: The initial ebXML business vocabulary - A call for
alistofcandidates


Abid,

There are lots and lots of technical hurdles still to solve in doing this.

I've received a number of suggestions for candidates for an initial ebXML
vocabulary and there are certainly some workable transaction sets there so
thank you everybody that has made a suggestion.

ebXML can progress quite well from the grass roots I believe and will have
it's best success if it does so this way. It's great to have the
participation of excellent large corporations and so forth but so far we
need to have more contributions that will help ebXML progress down to
enterprises at a lower level.

These are companies ones that don't require fully automated supply line
solutions for instance like EDI,  but need something a lot less complicated
to setup and get running.

Heading for the wider market instead of reinventing something that already
works quite well (EDI) seems a little pointless to me.

This can only in turn help the commercial providers of ebXML produce
products for people to buy.

It probably therefore makes sense that some Open Source development has to
become part of ebXML so that solution providers can take away the components
and them customise them for individual client requirements.

This would enable a revenue stream for all, and a high degree of
interoperability between systems.

Moving forward

David Lyon
ebXML Evangelist
Brisbane Australia

----- Original Message -----
From: Abid Farooqui <farooqui@tampabay.rr.com>
To: Rémy Marchand <rm-edi@worldnet.fr>; Cole, Wavell (GXS)
<Wavell.Cole@gxs.ge.com>; David Lyon <djlyon@one.net.au>; Mervyn Colton
<Merv@quest.ie>; <ebxml-dev@lists.ebxml.org>
Cc: Rachel Foerster <rachelf@ix.netcom.com>; Gilles Brandel
<Brandel.Gilles@srci.fr>
Sent: Thursday, June 21, 2001 9:48 AM
Subject: Re: The initial ebXML business vocabulary - A call for a
listofcandidates


> I think a lot of the hurdles found in not being able to use one format (a
> single business message suitable for every industry) are at least
> technically gone with the use of XML and XML schemas.
> However as Remy suggested we should also look at OO approach to this
problem
> as well. At this point there is no harm in trying to solve the problem
both
> ways and see which works better in reality scenarios. One can only do that
> if one has a demo implementation.
> That is my 2 cents.
> Sincerely,
> Abid Farooqui
>
>
> ----- Original Message -----
> From: "Rémy Marchand" <rm-edi@worldnet.fr>
> To: "Cole, Wavell (GXS)" <Wavell.Cole@gxs.ge.com>; "Abid Farooqui"
> <farooqui@tampabay.rr.com>; "David Lyon" <djlyon@one.net.au>; "Mervyn
> Colton" <Merv@quest.ie>; <ebxml-dev@lists.ebxml.org>
> Cc: "Rachel Foerster" <rachelf@ix.netcom.com>; "Gilles Brandel"
> <Brandel.Gilles@srci.fr>
> Sent: Wednesday, June 20, 2001 4:48 AM
> Subject: Re: The initial ebXML business vocabulary - A call for a list
> ofcandidates
>
>
> > Folks,
> >
> > Speaking in my quality of EFNET (European Footwear Network), I confirm
> that
> > GCI is a good starting point.
> >
> > The XML Schema for Catalogue data and product description contains a
group
> > of data which can be tailored to each product type, in particular shoes.
> >
> > According to me XML has to define Core Components such as Dates,
> Addresses,
> > Company and product Id etc..
> >
> > Unlike UNSM, which are supposed to give the framework for any Order,
> Invoice
> > etc..and which finally produced inconsistent MIGs, XML should adopt an
> > Object Oriented approach, which means defining the few information
parcels
> > which can be found in any business document, then defining the
additional
> > information parcels used by trading activities consumer oriented, then
> > defining additional information parcels which make sense in a particular
> > domain (textile, building and construction).
> >
> > This leads us to the idea of Core Components, and according to me we
> should
> > have Basic (general purpose) Core Components, Domain specific Core
> > Components, Sector specific Core Components.
> >
> > As an example, I refer you to the www.hr-xml.org, an organisation
working
> on
> > xml for human ressources management. They have defined all the possible
> > national expressions of the group of data "Address".
> >
> > Should we have more of such basic components, the work would become much
> > easier.
> >
> > Hopefully, this will be an output of the EAN-UCC work.
> > ----- Original Message -----
> > From: "Cole, Wavell (GXS)" <Wavell.Cole@gxs.ge.com>
> > To: "Abid Farooqui" <farooqui@tampabay.rr.com>; "David Lyon"
> > <djlyon@one.net.au>; "Mervyn Colton" <Merv@quest.ie>;
> > <ebxml-dev@lists.ebxml.org>
> > Sent: Sunday, June 17, 2001 12:59 AM
> > Subject: RE: The initial ebXML business vocabulary - A call for a list
> > ofcandidates
> >
> >
> > > Folks,
> > >
> > > The EAN-UCC Global Commerce Initiative (GCI) is providing an excellent
> > base
> > > from which EAN members all around the world can employ XML messaging.
> The
> > > GCI project is producing a suite of business messages based on the XML
> > > Schema (XSD). The first of the messages is expected to be made
> commercial
> > in
> > > July this year and I believe will become the 'standard' for at least
the
> > > Retail Industry in Australia.
> > >
> > > At least one of the major retailers has already commenced in earnest
to
> > > implement the purchase order and others will follow.
> > >
> > > Attempting to develop a single business message suitable for every
> > Industry
> > > participant has never worked in the past and I doubt that it ever
will.
> > > However, considering the extensibility structure of the XSD schema
this
> is
> > > not a problem. If there is acceptance of a base schema then an exact
fit
> > for
> > > a user is always possible.
> > >
> > > I have been working with the Retail Industry in Australia on the issue
> of
> > a
> > > single standard since the late 1980's and it is yet to be realised. It
> is
> > no
> > > wonder that there is a growth in service industries acting as
> > intermediaries
> > > to ensure trading partners send or receive messages capable of
> integration
> > > or least interfacing with their back-office systems.
> > >
> > > There is still a wide view that users will somehow cope with
technology
> > but
> > > in fact, they have no interest in doing so. The expectation is one of
> > > complete technology transparency. "Give me an order, do'nt tell me
what
> is
> > > looks like!". As long as technology is as simple as the act of making
a
> > > phone call, to end users that is all they want.
> > >
> > > Wavell Cole
> > >
> > > Snr. EC Consultant
> > > GE ecXpress
> > > Level 15, 565 Bourke St.
> > > Melbourne Vic. Australia 3000
> > > Office: 61-3-9927 2502, Fax 61-3-9629 8838
> > > Mobile: 0409 148 260
> > > Dial Comm 345 0002
> > > email: wavell.cole@gxs.ge.com
> > > WAP email: colew@telstra.com
> > >
> > >
> > >
> > > -----Original Message-----
> > > From: Abid Farooqui [mailto:farooqui@tampabay.rr.com]
> > > Sent: Sunday, 17 June 2001 3:27
> > > To: David Lyon; Mervyn Colton; ebxml-dev@lists.ebxml.org
> > > Subject: Re: The initial ebXML business vocabulary - A call for a list
> > > of candidates
> > >
> > >
> > > Mervyn,
> > > I just wanted to say that David Lyon is completely on target in my
> > opinion.
> > > A horizontal transaction set covering many industries is exactly what
I
> > have
> > > been asking this list about and it simply does not exist. I have been
> > given
> > > example scenarios where a PO format for aerospace would be very
> difficult
> > to
> > > be used as a PO format for some other industries. In my opinion that
was
> > not
> > > the case and the problem could be easily solved but I guess I was a
> > minority
> > > in that opinion at least in this list. Specifics like inspections of
> > > aerospace gear that conforms to ASME standards was sighted. Well, I
> always
> > > thought that ebxml worked under the UN not under the US. In either
case
> I
> > > had suggested that inspections may be a part of any PO (optional) not
> just
> > > for aerospace industry in the US.
> > > In short what I see happening is that while ebxml and related bodies
> wait
> > to
> > > theorize the whole deal in complex lingo and jargain, some of us will
> find
> > > things already out there and use them over ebxml messaging with the
CPP
> > etc.
> > > Will that make these products ebxml compliant. Yes, because lack of
> > > something cannot and should not force us ot to make a product that
> solves
> > a
> > > real need now.
> > > Sincerely,
> > > Abid Farooqui
> > >
> > >
> > > ----- Original Message -----
> > > From: "David Lyon" <djlyon@one.net.au>
> > > To: "Mervyn Colton" <Merv@quest.ie>; <ebxml-dev@lists.ebxml.org>
> > > Sent: Saturday, June 16, 2001 4:30 AM
> > > Subject: The initial ebXML business vocabulary - A call for a list of
> > > candidates
> > >
> > >
> > > > Mervyn,
> > > >
> > > > It's a funny thing about ebXML but I'm told that there are
> > > > actually *no* defined messages yet, in the traditional sense.
> > > >
> > > > Not at this point anyway.
> > > >
> > > > However, practical neccessity will no doubt overide the
> > > > technical theorists and purists. This has to happen for ebXML
> > > > to ever work.
> > > >
> > > > Where ebXML appears to be at the moment is that
> > > > there is a reluctance to make an executive commitment to
> > > > documenting some standard messages. This may be
> > > > due to lack of funds, or maybe a perceived difficulty
> > > > that a horizontal transaction set covering many industries
> > > > will be extremely difficult to do.
> > > >
> > > > No matter, grass-roots support, from participants all
> > > > around the world, especially in developing countries, is
> > > > leading to the invevitable conclusion that a third-party
> > > > business/messaging vocabulary must be picked up for
> > > > ebXML to ever work.
> > > >
> > > > The best way forward, rather than to build a new
> > > > vocabulary from scratch is to pick up and run with an
> > > > existing one. Then, over time, adapt that to suit
> > > > requirements.
> > > >
> > > > I've checked out www.xcbl.org and noticed that
> > > > above everything, they provide a reasonably workable
> > > > XML based transaction set that could be used as
> > > > the basis to build an ebXML transaction set.
> > > >
> > > > If there are any other candidates for an ebXML
> > > > then please mail me.
> > > >
> > > > As ebXML runs under the United Nations banner, it's
> > > > a responsibility for people in all nations accross the
> > > > world to have their say on how they would like ebXML
> > > > to go forward, not only those based in Europe or
> > > > America.
> > > >
> > > > Looking forward
> > > >
> > > > David Lyon
> > > > ebXML Evangelist
> > > > Brisbane Australia
> > > >
> > > >
> > > > ----- Original Message -----
> > > > From: Mervyn Colton <Merv@quest.ie>
> > > > To: Ebxml-Dev (E-mail) <ebxml-dev@lists.ebxml.org>
> > > > Sent: Friday, June 15, 2001 5:18 PM
> > > > Subject: Newby
> > > >
> > > >
> > > > > Hi All,
> > > > >
> > > > > I'm new to these email goups on ebxml. I would like to know if
there
> > is
> > > an
> > > > > URL that explains more on the scope of the different email groups,
> and
> > I
> > > > am
> > > > > specifically interested in where the different "messages" are
> defined
> > > for
> > > > > the FMCG business place. Product catalogs for example.
> > > > >
> > > > > Any tips on where to start looking would be very much appreciated.
> > Sorry
> > > > if
> > > > > this has been covered before.
> > > > >
> > > > > Mervyn Colton
> > > > > Technical Director
> > > > > merv@quest.ie
> > > > > Quest Computing Ltd
> > > > > www.quest.ie
> > > > >
> > > > >
> > > > > ------------------------------------------------------------------
> > > > > The ebxml-dev list is sponsored by OASIS.
> > > > > To unsubscribe from this elist send a message with the single word
> > > > > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> > > > >
> > > >
> > > >
> > > > ------------------------------------------------------------------
> > > > The ebxml-dev list is sponsored by OASIS.
> > > > To unsubscribe from this elist send a message with the single word
> > > > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> > > >
> > >
> > >
> > > ------------------------------------------------------------------
> > > The ebxml-dev list is sponsored by OASIS.
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> > >
> > > ------------------------------------------------------------------
> > > The ebxml-dev list is sponsored by OASIS.
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
> > >
> >
>
>
> ------------------------------------------------------------------
> The ebxml-dev list is sponsored by OASIS.
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org
>


------------------------------------------------------------------
The ebxml-dev list is sponsored by OASIS.
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: ebxml-dev-request@lists.ebxml.org