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

[Stuart Campbell <stuart.campbell@tieglobal.com>]

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