[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Getting Back to Basics - How to describe Dates and Times andEvents?
Hello Stuart, It seems to me there should be some kind of rule to decide whether something is a 'coded list' or whether it is a 'class' i.e tag. For example it would be silly if every country were to be a class i.e tag e.g <UK> </UK> etc. even worse it would be silly to have each UN-LOCODE as a tag (there are about 30,000 of these). But should each party have its own tag ? Another good reason for having code lists, is the fact that you can add codes to a list, but adding a new tag will mean that DTDs/Schemas will have to change and s/w may have to be re-engineered. Anyone with any thoughts on this ? Cheers, Phil ----- Original Message ----- From: "Stuart Campbell" <firstname.lastname@example.org> To: <email@example.com>; "'William J. Kammerer'" <firstname.lastname@example.org>; "'ebXML Core'" <email@example.com> Sent: Monday, April 09, 2001 7:45 PM Subject: RE: Getting Back to Basics - How to describe Dates and Times andEvents? > Todd > > I havnt followed all this thread so im mainly reacting to your specific > email (below) > > It reminds me of the discussion in EDIFACT of generic vs specific. If you > wish to, you could design any EDIFACT message with just two user segments - > FTX (free text) and ATT ('structured' attributes). If you really wanted to > you could wrap them both in a segment called XYZ with a qualifier, a value > field and loop the segments to create the relationships. Looks a little > like your examples i think and therein lies my problem. > > The benefit of XML is that the elements are user defined-the extensible > part- if this is so, then you would think that users who are going forward > with XML do so because they would like to set elements which are more > specific/known to them and get rid of all this genericity. The last thing > i want in a (typical) order of 10 or so fields is to see 50 elements to cope > with all the <code this> <qualifier that> etc. That is precisely the > problem with EDIFACT. > > On the other hand i do believe there is room for generic elements like code > list, date etc but they should be used where a good specific solution doesnt > exist. Ie go for the specific first and generic second. However i would > not of course like to see elements for 'stuarts_order_date_if_its_tuesday' > > Regards > > > > STUART > Technical Strategy Director, Technical Strategy Team > Business Development Unit > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Stuart Campbell > TIE Holding NV > UK T:+44 1270 254019 F:+44 7971 121013 > Netherlands T:+31 20 658 9335 F:+31 20 658 9901 > Global M:+44 7970 429251 E:stuart.campbell@TIEGlobal.com > W:www.TIEglobal.com P:www.stuartcampbell.co.uk > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > -----Original Message----- > From: Todd Boyle [mailto:firstname.lastname@example.org] > Sent: Monday, April 09, 2001 08:10 > To: William J. Kammerer; ebXML Core > Subject: RE: Getting Back to Basics - How to describe Dates and Times > andEvents? > > > Yes, as you said, I drop all of the specifically-named > date and accounting period elements from my General Ledger > schema... and substitute the following model: > > <transactionDate> > <qualifier>AnyEdifact2005qualifier</qualifier> (optional) > <date>yyyy-mm-dd</date> (required) > <time>hh:mm:ss</date> (optional) > <timezone>zz</timezone> (optional) > <transactionDate> > > The principle of avoiding specifically-named elements applies > in numerous other places in a GL schema. For example you would > avoid elements like "invoiceNumber", "poNumber", etc. and instead, > use something like Edifact 1153 strings, > > <docRef> > <docType>Invoice</docType> (required) > <docNum>ABC-12345</docNum> (required) > </docRef> > > And > > <code> > <codeList>DUNS</codeList> (required) > <codeValue>999999999</codeValue> (required) > </code> > > On the other hand, if you want adoption by small developers, > the basic framework around these meta-meta structures must > be clean and easy. > > For the record there is a good argument on this exact topic, > http://www.xedi.org/presentations/ebxml/sld016.htm > > (I am not necessarily promoting their 1999 solution however.) > http://www.xedi.org/presentations/ebxml/sld025.htm > > Sue Probert's report on Pharos http://www.edipro.no/pharname.htm last > year is helpful, as is Sintef report on Pharos. > http://lists.ebxml.org/archives/ebxml-core/200008/pdf00000.pdf > > Hope this helps somebody. And, any comments on my three objects > would be most welcome. > > Todd > > > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: email@example.com > > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: firstname.lastname@example.org >
Powered by eList eXpress LLC