Re: To get things started.... the Asian ebXML perspective..

[David Lyon <djlyon@one.net.au>]

Betty Thanks,

> The @ and the $ are not valid name characters in XML so they cannot
> be used in either element or attribute names.

We don't use these characters as as name characters in attribute names.

> Why not use the ISO 8601 and W3C Date format of CCYY-MM-DD or 2000-08-18.
> Parsers will eventually recognize this format and date datatype for free.

Our parsers already are able to read dates when they are encodedin the ISO
8601 or W3C date format. The example was encoded for domestic use here.

As you would be aware though, people in different countries around the world
have different conventions for writing dates. Not everybody (read the
business user) in every country is able to understand what are basically
American date formats.

Going backwards (to something EDI like) where the dates are in a fixed
format is not a very good move. Software these days can easily encode/decode
dates going to/coming from a number of locales, so why not give the
processors an extra few nanoseconds of work to do.

The really important thing is to focus on enabling ebXML to deliver
something that can be put to practical use. Our current systems work and we
are looking forward to changing them over to ebXML whenever that eventually
becomes possible. That's all we want to do.

What you may not be aware of is the completely different perspective that
Asian/Australian companies have when compared to American and European
companies in terms of expectations of ebXML.

Companies in developed countries have had access to EDI technology and many
already have it running. For them, ebXML is going to be something that they
are looking to change-over to eventually. To upgrade their existing systems,
many of which are architectually over 20 years old (shows how good EDI was
for it's day).

Accross Asia, ebXML is something that many companies would be looking to
pick up and implement without having to go through the same pain of
implementation and development that developed countries did. They'll just
pick it up and run with it.

For example, an Indian handicrafts company wants to sell shoes in Europe.
They'll use a digital camera, photograph their products, and before you know
the products will be for sale accross Europe, ready to take orders on.

In countries like Hong Kong, Taiwan, Japan, people will want to sell
electronics products as they are already doing. It won't take them to long
to get the systems going, they are quite clever and hardworking people.

What they might not have however, is the vision and leadership, combined
with a working knowledge of the benefits that EDI (like) systems can bring.

This is why ebXML, which purports to be a global and U.N. effort, has so
much more potential than many other proprietory solutions. For this to
happen, It does need to deliver something that people are able to use to
build the systems. At this point, it still seems to have a long way to go
but maybe it's on the right track, who knows.

Take care

David Lyon



----- Original Message -----
From: Betty Harvey <ebxml@eccnet.eccnet.com>
To: David Lyon <djlyon@one.net.au>
Cc: <ebxml-dev@lists.ebxml.org>; <ebxml-core@lists.ebxml.org>
Sent: Thursday, May 31, 2001 10:45 AM
Subject: Re: To get things started.... Data formats


>
>
> David and Todd:
>
> The @ and the $ are not valid name characters in XML so they cannot
> be used in either element or attribute names.
>
> Why not use the ISO 8601 and W3C Date format of CCYY-MM-DD or 2000-08-18.
> Parsers will eventually recognize this format and date datatype for free.
>
> Betty
>
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
> Betty Harvey                         | Phone: 410-787-9200 FAX: 9830
> Electronic Commerce Connection, Inc. |
> harvey@eccnet.com                    | Washington,DC SGML/XML Users Grp
> URL:  http://www.eccnet.com          | http://www.eccnet.com/xmlug/
> /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\\/\/
>
>
> On Thu, 31 May 2001, David Lyon wrote:
>
> > Todd, all,
> >
> > > That is a lot of work ---and I will do it---as soon as these three
vendors
> > > give me permission to post parts of their docs.
> >
> > It's good see that you are taking on the weight of the world, old
Atlas...
> > but other people may have be able to put in valuable input also
> >
> > > My recommendation will be that these SME XML's must converge a lot of
> > > things.  For example here are three date formats and address formats
used
> > by the three companies.
> > >
> > > IntAcct
> > >      <datecreated>
> > >         <year>2000</year>
> > >         <month>8</month>
> > >         <day>18</day>
> > >     </datecreated>
> >
> > This is such a cumbersome mechanism. Both to code, as well as for the
> > business user to understand.
> >
> > Here in Australia we've been using an approach which simplifies this to:
> >
> >  datecreated@="18-July-2000"
> >
> > It's much easier to parse, and is far less prone to error than the first
> > example.
> >
> > All of the datatypes get their own denominator, for example:
> >
> >  String fields,       terminated with "&",    eg Address&="23 River Rock
> > Road"
> >  Currency fields,  terminated with "$",     eg Amount$=356.24
> >  Boolean fields,    terminated with "?"      eg Receipt_Required?=True
> >  Date fields,         terminated with "@"    eg
> > Shipping_Date@="28-October-2001"
> >  Integer fields,      terminated with "#",    eg Quantity_Required#=3
> >
> > Fields are then built in blocks:
> >
> > <?ebxml Document, version#=1.0, encoding&="UTF-8">
> > <!DOCTYPE "Purchase Order">
> > <Purchasor Details>
> >   Company_Name&="Hotwire Business Systems"
> >   Address_Line_1&="38^/332 Handford Road"
> >   Address_Line_2&=""
> >   Suburb_City&="Taigum"
> >   Region_State&="QLD"
> >   Postcode_ZIP&="4018"
> >   Country&="Australia"
> >   Telephone&=""
> >   Fax&=""
> >   Contact&="David Lyon"
> > </Purchasor Details>
> > <Vendor Details>
> >   Company_Name&="Backpackers by the Beach"
> >   Company_Address&="^m"
> > </Vendor Details>
> > <Delivery Details>
> >   Delivery_Mode&=""
> >   Delivery_Date@=20-March-2001
> >   Delivery_Address&=""
> >   Delivery_Instructions&=""
> > </Delivery Details>
> > <Order Item List>
> >   <Order Item>
> >     Code&="290"
> >     Name&="Female Dormitory Bed"
> >     Description&="Arriving Mon 21-05-01 2:12:51 PM, Departing Tue
22-05-01."
> >     Quantity#=2
> >     Rate$=90
> >     Tax$=0
> >     Amount$=180
> >   </Order Item>
> > </Order Item List>
> >
> > Regards
> >
> > David Lyon
> >
> > ----- Original Message -----
> > From: Todd Boyle <tboyle@rosehill.net>
> > To: William J. Kammerer <wkammerer@foresightcorp.com>; ebXML Development
> > <ebxml-dev@lists.ebxml.org>
> > Cc: ebXML Core <ebxml-core@lists.ebxml.org>
> > Sent: Thursday, May 31, 2001 3:40 AM
> > Subject: RE: To get things started....
> >
> >
> > > William J. Kammerer said,
> > > > Todd Boyle "urge[s] the EWG to accord a high priority to publishing
a
> > > > common horizontal set of components at an early date.  This should
> > > > include all party, product, location, contact and other aggregates
> > > > necessary for the 30 million small and medium businesses (SMB's) in
the
> > > > US to begin automating their bookkeeping."  Todd explains that
"[the]
> > > > ongoing cost of printing and mailing paper checks, and altogether
> > > > unreconciled bookkeeping mess are a national disgrace, running well
> > > > above $100 billion/year."  >>I will not argue about wherever Todd
> > > > came up with that $100 billion/year figure.
> > >
> > > Here was my calculation.
http://www.gldialtone.com/survey_of_waste.xls
> > >
> > > Whoops I was off by 1.9 Trillion
> > > http://www.unece.org/press/pr2001/01trade04e.htm  or is that 2.9
Trillion,
> > > Ray?
> > > Oh well, a trillion here, a trillion there.. whatever.  If Ray Walker
is
> > > right, then every day we goof off here in Core Components is costing
the
> > > world $10 billion!  In fact, my recent post about qualifiers is the
only
> > > technical post for the past three days, so you guys owe me $30
billion!
> > >
> > > > Todd should share with Core Components his idea (model) of what
these
> > > > "party, product, location, contact and other aggregates" look like.
It
> > > > would be preferable that he not refer us to OAG, xCBL, Intuit and
qbXML
> > > > to find out for ourselves.
> > >
> > > I have been working, quite persistently behind the scenes here, to get
> > > NetLedger, Intuit and Intacct to work together and converge their XML
> > > schemas (SMBXML, QBXML and Intacct XML)
> > >
> > > I have some comparisons I've done privately but need their permission
> > > to post their schemas and parts of the docs in order to talk about
them.
> > >
> > > I also have requested some indication whether the idea of
standardization
> > > is a dead issue for them.  Obviously, people will need to know that.
> > >
> > > > I could provide a model of these aggregates, but they would probably
> > look
> > > > a lot like EDIFACT - so I implore Todd to come up with his own.
> > >
> > > That is a lot of work ---and I will do it---as soon as these three
vendors
> > > give me permission to post parts of their docs.  My recommendation
will
> > > be that these SME XML's must converge a lot of things.  For example
here
> > > are three date formats and address formats used by the three
companies.
> > >
> > > IntAcct
> > >      <datecreated>
> > >         <year>2000</year>
> > >         <month>8</month>
> > >         <day>18</day>
> > >     </datecreated>
> > >
> > >    .Mailaddress: Optional. Mail address specific information.
> > >    Mailaddress Sub Elements:
> > >    .address1: Optional.
> > >    .address2: Optional.
> > >    .city: Optional.
> > >    .state: Optional.
> > >    .zip: Optional.
> > >    .country: Optional
> > >
> > > NetLedger
> > >
> > >    <postDate>01/14/2001</postDate>
> > >
> > >    <shipAddress>Bailey's Training Services&#xD;950 E. Algonquin
> > > Road&#xD;Arlington
> > >    Heights IL 60005</shipAddress>
> > >
> > > Intuit (QBXML is not finished or fully documented but has clues:)
> > >
> > >    <!ENTITY % DATETYPE "(#PCDATA)">
> > >
> > >    <!ENTITY % AddressDataMacro "(Addr1? , Addr2? , Addr3? , Addr4? ,
City?
> > ,
> > >     State? , PostalCode? , Country?)">
> > >
> > >
> > > The biggest problem with these XML interface schemas is that they have
> > > processing commands deeply interwoven with all the business data
> > > content.  Approximately the top 1/3 of the XML instances are going to
be
> > > invoking methods on the host or application.  This is how OAGIS BODs
> > > work.  These three SME applications are more different in their
> > > processing than in the content of the screens for a PO, invoice,
> > > payment etc. so there are major dependencies in the schemas that are
> > > just a distraction, if you're working on standardization.
> > >
> > > There is a very huge need for separating processing logic from the
data
> > > content in A2A integrations with these products, if we are ever going
to
> > > get anywhere with integration with SME software.  Then we can all
benefit
> > > from the diversity in application services, not least these Vendors.
> > >
> > > Business Processs and Collaboration Patterns work of ebXML for B2B
> > > interactions needs to be extended across the border to the accounting
> > > and business applications. These vendors are still stuck with the old
> > > model of "my application, my interface".  That's ok-just 5 years ago
> > > we were thrilled that a program even had an interface!   But now, the
> > > interface language has to be understandable -we can't deal with a
doctor
> > > or a carpenter or a waitress if they speak a different language.  So,
> > > they don't get a job until they learn the language of the country they
> > > live in.
> > >
> > > I think the Vendors are emotionally confusing the issue of
standardization
> > > of business process interfaces, with standardization like CORBA or
DCOM.
> > > When CORBA or DCOM or Sun's Java changes, it forces deep changes in
your
> > > code just to stay alive.  But the BP layer does not specify that level
> > > of the protocol stack, any more than it contains business data like
> > > shipping address or product codes.  The BP layer, TP layer and
messaging
> > > has been explained a lot better in the specs than what I'm doing here.
> > >
> > > What the application is going to see coming from the TP and BP layers
> > > to/from 3rd parties is precisely defined business documents, within a
> > > very tightly defined set of request and response containers or sort of
> > > framework.  The application vendor benefits because there is a data
> > > dictionary, business docs, and a framework for specifying requests
> > > and responses that is cross platform.
> > >
> > > My job is to get some (bleepin') business vocabulary that I can
> > > understand, and then buy some business collaboration manager (BCM)
> > > software that does these service layers for my application, that
> > > doesn't cost $4 figures.
> > >
> > > http://lists.ebxml.org/archives/ebxml-bp/200012/msg00014.html
> > > http://lists.ebxml.org/archives/ebxml-bp/200012/msg00020.html
> > >
> > > Ok here is my own thinking and this is no guarantee.
> > >
> > > The non-interoperable XML schemas from Intuit, NetLedger and Intacct
> > > are useless in themselves.  You could design better data aggregates by
> > > going to the user interface on these application to identify the kinds
> > > of information they support, and then highlighting the corresponding
> > > elements in in the Core Components dictionary with a marker pen.  This
> > > would take about an hour.
> > >
> > > You could identify the common requirements from among their control
> > > structures
> > > by simply reading the instance docs, and implementing them the
standard
> > > way with CPP/CPA and in the BPSS.  They all have very simple stuff
like
> > > login Id, company Id, transaction Ids, Add, Update, Delete, etc.  The
fact
> > > that ebXML didn't specify A2A integration is not really fatal, I
think,
> > > because you could still use the B2B oriented services to encapsulate
your
> > > own A2A/CRUD methods.  It is these methods that we need to get the
Vendors
> > > to standardize so we can stream them thru the BSI.  And Vendors will
need
> > > to figure out standards for accounting recognition events to local
> > > applications, since ebXML BPSS doesn't seem to inform both parties,
> > > simultaneously, of both sides of the reciprocal movements they have
> > > executed.
> > >
> > > I am a GL looking for A2A integration but all my clients are web
> > > services companies and they are going to use BCMs to conduct
> > > busines on the internet.  So, I can either ask them to install my
> > > queer proprietary interface or learn how to talk to their BCMs.
> > >
> > > Todd
> > > Todd Boyle CPA   (425) 827-3107
> > > 9745-128th Av NE, Kirkland WA 98033
> > > func architect, NetAccount AS, Oslo, NO
> > > tboyle@netaccount.com  http://www.netaccount.com/
> > > tboyle@rosehill.net  http://www.gldialtone.com/
> > >
> > >
> > > ------------------------------------------------------------------
> > > To unsubscribe from this elist send a message with the single word
> > > "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
> > >
> >
> >
> > ------------------------------------------------------------------
> > To unsubscribe from this elist send a message with the single word
> > "unsubscribe" in the body to: ebxml-core-request@lists.ebxml.org
> >
>
>