Subject: Re: date/time (was RE: To get things started.... Data formats
Hello there, I believe there were 3 recommended 'variations' of date time etc in XML 1.0 date YYYY-MM-DD dateTime YYYY-MM-DDThh:mm:ss dateTime.tz YYYY-MM-DDThh.mm.ss-hh:mm All are subsets of the ISO8601 Cheers, Phil ----- Original Message ----- From: "Chuck Allen - HR-XML" <chucka@hr-xml.org> To: <ebxml-core@lists.ebxml.org>; <ebxml-dev@lists.ebxml.org> Sent: Monday, June 04, 2001 6:36 PM Subject: FW: date/time (was RE: To get things started.... Data formats > Betty Harvey wrote: > > 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. > > The date, time and dateTime data types provided in the > Schema Recommendation are an obvious place to start - but > there can still be a lot of design issues depending > on what you need to support. > > The HR-XML Consortium's Cross Process Workgroup has begun > taking a look at various approaches for capturing date > and time information within XML schema. Some of the > scenarios we need to support in the human resource > management space are particularly complex. The > preciseness of the date/time value is often dependent > on the business context. For instance, a hire date can > often be captured as date value, the exact time a person > is hired is not important to most systems. An incident > date requires more precision. Most systems require the > date and time an incident took place. Also, in the case > of an incident, the time zone may be required. Eleven > o'clock in the evening on July 31 in Washington DC, is > four o'clock in the morning on August 1 in London. This > could mean a difference in coverage for the employee. > > Anyone interested in this work, may want to review > these drafts: > http://docs.hr-xml.org/HR-XMLDateTimeDataTypes2001-05-23.pdf > http://docs.hr-xml.org/HR-XMLEffectiveDating06-03-2001.pdf > These are obviously snap shots of work-in-progress documents. > As such, they do not necessarily represent any sort of > consensus opinion of Consortium members. Feel free to > comment - or contact me if you are interested in participating > in this work. > > Best Regards, > > Chuck Allen > Director, HR-XML Consortium, Inc. > http://www.hr-xml.org > > -----Original Message----- > From: Betty Harvey [mailto:ebxml@eccnet.eccnet.com] > Sent: Wednesday, May 30, 2001 8:45 PM > To: David Lyon > Cc: ebxml-dev@lists.ebxml.org; ebxml-core@lists.ebxml.org > 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
950 E. Algonquin > > > Road
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 > > > > >
Powered by
eList eXpress LLC