[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Summary of XML Datatypes as required for B2B applications
Stephane,
I asked the UML modelers to respond to your comment, and they were in
agreement. In fact, in later work (PO) they have modeled the dates in the
Purchase Order as suggested, and we will modify the Item Sync. to look the
same way. Part of this is the incremental nature of development - the Item
Sync was first. The Purchase Order is not a finished product either but is
much closer.
The mapping of UML to XML: The UML models are a logical design upon which
the XML schemas will be based. There should be enough in the UML to
describe all of the data elements and their relationships for the XML
schemas. Again, this is an incremental process - to uncover the data
elements, their relationships, cardinality, etc. The UML is also meant to
be syntax independent so that other formats can be supported and
interoperability across formats is maintained.
Melanie Kudela
EC Technical Manager
UCC, Inc.
Princeton Pike Corporate Center
1009 Lenox Dr., Suite 202
Lawrenceville, NJ 08648, USA
609-620-4514
mkudela@uc-council.org
Canon
Stéphane To: "'MKudela@uc-council.org'"
<stephane.can <MKudela@uc-council.org>, tboyle@rosehill.net
on@GIB.BE> cc: ebxml-core@lists.oasis-open.org,
owner-ebxml-core@lists.oasis-open.org,
04/18/00 xmledi-list@lists.bizserve.com
09:33 AM Subject: RE: Summary of XML Datatypes as
required for B2B applications
Melanie,
I fully agree with you :
1. Edi knowledge should be reused
2. Xml standards development process should follow some kind of
methodology (and UML seems to be a good choice).
Could you provide more information about :
1. your model : I see a class Dates containing different dates as
data members (Start Availability Date, End Availability Date, ...). The
"normal" way to model would have been to create a class Date and to derive
the other dates from this class. Why did you model this way ? Don't you
think this approach will cause a problem if you want to reuse your Dates
class ?
2. the mapping between UML concepts and XML
Thanks,
Stephane
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
At UCC we provide UN/EDIFACT and X12 EDI support for our members'
supply
chains. Through tour work we contribute to such global efforts as the
Global Data Alignment Specifications (GDAS) and GEDI data
dictionaries.
We are also building a bridge for our member companies to cross from
EDI
and manual transactions to XML. We support all members, whether they
exchange information with EDI-enabled buyers or smaller SMEs not
currently
using EDI. We also expect to support our members with a global
standard.
Therefore, out position is that the EDI data dictionaries, in essence,
repositories of business process, are of immense value as input into
the
XML standards process. In fact, we reuse this EDI knowledge in our XML
effort, as you can see in the UCC Electronic commerce attachments with
this
mailing.
However, the EDI knowledge should not be the only input to the process
.
Because of our history of working with our members on EDI industry
standards, we know we must adhere to two principles when we define the
XML
standards roadmap for our members:
1. accomodate the business needs, and
2. standards do not drive business behavior, but accommodate
business
behavior.
The EDI inputs are not sufficient by themselves to describe the
business
landscape of tomorrow. Converting EDI to XML in n number of days is
possible, but not enough to accomodate business behavior. That is why
the
UCC program consists of
1. a business model represented in UML which is developed with
the
business community;
2. a data dictionary which is based on EDI knowledge but is not a
one-for-one map of EDI to XML;
3. a set of XML metadata which is derived from 1. and 2. and the
resultant XML schema.
We would like to see the ebXML Core Components define a documented
set of
standard of core components in XML, down to the level of the
document,
"Using XML Schemas to define B2B Datatypes", so that we could comply
to
these core component definitions.
I'm contributing a draft of the UML model, data dictionary and
schemas of
a business process that we are currently working on with our members
where
we address our member needs for synchronizing product and service
information between buyers and suppliers. Both business needs and EDI
knowledge have been useful in gathering the information. We also have
work-in-progress in other areas, such as pricing, markets, purchasing.
Standard, agreed upon core components from ebXML would facilitate the
ease
of adopting these XML transactions for our members.
(See attached file: Item Sync_all_04_12.doc)(See attached file:
ItemSync32800.doc)
Melanie Kudela
EC Technical Manager
UCC, Inc.
Princeton Pike Corporate Center
1009 Lenox Dr., Suite 202
Lawrenceville, NJ 08648, USA
609-620-4514
mkudela@uc-council.org
"Todd Boyle"
<tboyle@rosehill.net> To: "Ian
Galbraith"
Sent by:
<ian@oms-services.com>, "'ebXML Core
owner-ebxml-core@lists.oasi Components
(E-mail)'"
s-open.org
<ebxml-core@lists.oasis-open.org>, "William
J. Kammerer"
<wkammerer@foresightcorp.com>
cc: "David"
<realtime@anywhere.co.uk>,
04/17/00 01:43 AM "XML/EDI Group
(E-mail)"
Please respond to tboyle
<xmledi-list@lists.bizserve.com>
Subject:
RE: Summary of XML Datatypes as
required for
B2B applications
EDI users often wax poetic about EDI. But small business simply
cannot
afford transaction connectivity having any component of labor cost.
Ian, you said "conversion of EDIFACT dictionaries" would not be
difficult;
please provide a definitive example, into an XML DTD or schema that
would
be useful for small business, in the exchange of business messages.
EDI requires human negotiation and setup, causing costs for users, and
revenues for EDI vendors. Does EDI have a suitable unambiguous
subset?
Does EDIFACT provide definitions of semantic meanings or business
process?
Does EDIFACT imply any consistent data model, cleansed of overlapping
synonyms, duplicated structures, and collisions?
Small business has no choice but to wait, and do NOTHING, until
transaction
cost of ecommerce comes way down. That might happen via XML if an
unambiguous
vocabulary emerges from ebXML. Or, it might happen within various
commercial
portals, Microsoft, Checkfree, AOL, etc. Right now the SMEs continue
printing
and mailing their checks and invoices, biding their time. The
commercial
companies are *miles ahead* of anything on this ebXML list. Every day
you
waste, the commercial companies sign up 100,000 more people and their
unit
costs go down, and their rent-collecting models take firmer root. For
example,
X.Com/PayPal has gone from zero to 1,000,000 users in the last 4
months,
Respectfully,
Todd Boyle
Ian Galbraith said Sunday, April 16, 2000 8:34 AM on the ebXML Core
Components
list, and XML/EDI Group Re: Summary of XML Datatypes as required for
B2B
applications
> Oh William, how right you are! The EDIFACT dictionaries (and the
rest)
have
> evolved through years of consideration of real user needs; it is not
a
big
> deal to convert the essential semantic content of these dictionaries
into
a
> different syntactic environment. This was exactly the intent behind
EDML.
> The EDML proof of concept work demonstrated a means of transferring
semantic
> content (ie data dictionaries) developed for one syntactic message
structure
> into a quite different syntactic structure. So to my mind an
obvious way
to
> accelerate the development of XML-based ecommerce would be to
exploit the
> EDIFACT (and other) data dictionaries. But right now I don't have
much
> confidence that the good bits of EDIFACT, X12, HL7, etc will
actually be
> exploited. It seems perhaps, that in rejecting the syntactic
structures
of
> "traditional" EDI the semantic baby is being thrown out with the
bathwater.
>
> Best regards
>
> Ian
>
> -----Original Message-----
> From: William J. Kammerer <wkammerer@foresightcorp.com>
> To: 'ebXML Core Components (E-mail)'
<ebxml-core@lists.oasis-open.org>
> Cc: XML/EDI Group (E-mail) <xmledi-list@lists.bizserve.com>
> Date: 15 April 2000 15:12
> Subject: Summary of XML Datatypes as required for B2B applications
>
>
> >There's an interesting thread entitled "Summary of XML Datatypes as
> >required for B2B applications," started by Martin Bryan, with
commentary
> >by Messrs. Kotok, Folkerts, and Haugen, on the XML-EDI mailing
list. See
> >http://www.mail-archive.com/xmledi-list%40lists.bizserve.com/ for
the
> >archives.
> >
> >Note that EDIFACT is being re-invented all over again, especially
the
> >MEA, CUX and DTM segments. Bob Haugen says:
> >
> > I think all of your other suggestions are essential to business
> > communications. One thought: if you left the timestamp off
> > the currency and put it on the business event (which needs it
> > anyway), then your measurements and currencies
> > would have the same structure ( amount and unit). This could
> > mean one structure for measurements of all resources.
> >
> >Absolutely brilliant! Can't argue with this - building up semantic
> >meaning from lego blocks. EDIFACT does this already with the
standard
> >CUX (Currencies) - DTM (Date/time/period) segment group. X12 does
also,
> >to some extent, but tends to overload its segments semantically
(e.g.,
> >the X12 CUR segment includes the date and time itself, and does not
> >rely on a separate segment to convey the exchange period).
> >
> >EDIFACT has been around for over a decade, and apparently is too
complex
> >to use (because of the semantic building block concept?).
Otherwise we
> >wouldn't be all scrounging around trying to reincarnate EDI in XML
> >syntax.
> >
> >But I do like the concept of semantic building blocks or core
> >components. So why re-invent them from scratch? Just take a look
at
> >the EDIFACT directories and dictionaries, and all of the core
components
> >for ebXML can be effortlessly extracted.
> >
> >Or, why don't we just use EDIFACT for ebXML: warts, delimiters, and
all,
> >and save ourselves a heck of a lot of time and trouble?
Because that wouldn't save non-EDI users any time or trouble, and
there are
hundreds of millions of non-EDI consumers and small businesses in the
developed countries who need to conduct business over the internet.
EDI has had its chance but the numeric codes and secret terms like
MEA, CUX and DTM are never going to make it. Rescue yourself before
all of EDI goes down the tubes: Spin off a subset that is more
acceptable
to the broader public. That's what SGML did. Look what happend to
X.500.
The whole wide internet has such a *hopelessly* large range of users
that
the perimeter of common vocabulary is going to be smaller. There is a
mathematical law at work, like when you draw 1,000 circles on a venn
diagram. You are not going to satisfy a large percentage of the needs
of all users, like you did with EDI. With EDI you would create
another
100 elements and satisfy in another 5% of the needs. This is a
different
game with a long tail: once you get up around 500 elements, you only
get
another 1% of the needs from another 100 elements so it's hardly worth
the trouble. Accordingly the game is less fun but it is a lot easier:
just identify 300 or 400 core elements, and quit.
The form of the new XML could be very simple and obvious. It would
need
to provide for extensibility but the core vocabulary is something you
could
launch in 30 days out of the common denominators between EDIFACT and
the existing XML vocabularies.
TOdd Boyle CPA Kirkland WA
> >William J. Kammerer
> >FORESIGHT Corp.
> >4950 Blazer Memorial Pkwy.
> >Dublin, OH USA 43017-3305
> >(614) 791-1600
> >
> >Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> >"Commerce for a New World"
>
<< File: Microsoft Word 4 >> << File: Microsoft Word 4 >>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC