Re: Getting Back to Basics - How to describe Dates and Times andEvents?

[Philip Goatly <philip.goatly@bolero.net>]

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" <stuart.campbell@tieglobal.com>
To: <tboyle@rosehill.net>; "'William J. Kammerer'"
<wkammerer@foresightcorp.com>; "'ebXML Core'" <ebxml-core@lists.ebxml.org>
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:tboyle@rosehill.net]
> 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: 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
>