[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
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 >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC