Re: To get things started.... Data formats

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

Betty,

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

Yes they can. XML can be made to do anything you want with it. That's why
it's called "extensible", because it can be extended.

It's a flexible technology that is able to adapt to modern business needs.

If you think the technology is static, then you should remember that in the
old days, people said that you couldn't sail too far out to sea or you'd
fall off the end of the earth.

I do admit we are stretching the bounds of XML and make no apology for it.
Actually the '$', '@', '#', '?' specifiers don't form part of the element
name as you say they do. They simply denote the type of data that is stored
so that the values can be safely read and converted to a different data-type
if that is neccessary.

Hence, Transaction_Amount can be expressed either as
Transaction_Amount&="34.56" (a string), or as Transaction_Amount$=34.56 (a
currency field). They're both talking about the same data element, which is
Transaction_Amount.

Thanks for your comments in any case.

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
> >
>
>