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

[Betty Harvey <ebxml@eccnet.eccnet.com>]

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
>