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

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

My mistake folks this should have gone to all the group. :-(

Cheers, Phil


----- Original Message -----
From: "William J. Kammerer" <wkammerer@foresightcorp.com>
To: "Philip Goatly" <philip.goatly@bolero.net>
Sent: Thursday, April 12, 2001 1:42 PM
Subject: Re: Getting Back to Basics - How to describe Dates and Times
andEvents?


> These are great questions that can and should be posted to the entire CC
> mailing list, even if it makes some people mad.  One of the complaints
> I've had about CC has been the official little cliques that do
> everything in the background off the mailing list.  This isn't the same
> thing, but it would be helpful for everyone to see your discussion.
>
> Thanks,
>
> William J. Kammerer
> FORESIGHT Corp.
> 4950 Blazer Pkwy.
> Dublin, OH USA 43017-3305
> +1 614 791-1600
>
> Visit FORESIGHT Corp. at http://www.foresightcorp.com/
> "accelerating time-to-trade"
>
> ----- Original Message -----
> From: "Philip Goatly" <philip.goatly@bolero.net>
> To: <tboyle@rosehill.net>
> Cc: "Morten Jacobsen" <morten@netaccount.com>;
> <stuart.campbell@tieglobal.com>; "William J. Kammerer"
> <wkammerer@foresightcorp.com>; "Peter Guldentops"
> <peter.guldentops@bolero.net>; "Zahida Christie"
> <zahida.christie@bolero.net>
> Sent: Thursday, April 12, 2001 4:18 AM
> Subject: Re: Getting Back to Basics - How to describe Dates and Times
> andEvents?
>
>
> Hi Todd,
>
>  You say
>
> > 1.  Human readability by domain experts as well as software
> specialist,
> > is a requirement.
>
>  Yes true, but if we were to adopt a 'code' as a tag then it would still
> be
> human readable i.e it is ASCII but the meaning would be obsured to the
> casual/uneducated reader. It is not beyond the wit of comptuing to look
> up
> the 'code' and make it friendly to the casual reader. Also, given the
> human
> reader could have some language other than English as his/her mother
> tongue,
> then the look up could be keyed on Language Code + tag code. Is this
> even
> better than having a long English tag?
>
> Even with 'long' tag names, which allow readability in English, there
> still
> remains a problem in that the tag does not convey the complete meaning -
> otherwise we would not need any semantics at all.
>
> Again we must ask a similar question to the one which I posed before.
>
> How much of the semantics should be in the tag and how much in the
> actual
> semantic description of the element.
>
> There is a temptation to write an 'essay' in the tag.
>
> Anybody got thoughts on this one ?
>
> Cheers, Phil
> ----- Original Message -----
> From: "Todd Boyle" <tboyle@rosehill.net>
> To: "Philip Goatly" <philip.goatly@bolero.net>
> Cc: "Morten Jacobsen" <morten@netaccount.com>;
> <stuart.campbell@tieglobal.com>; "William J. Kammerer"
> <wkammerer@foresightcorp.com>
> Sent: Tuesday, April 10, 2001 9:21 PM
> Subject: RE: Getting Back to Basics - How to describe Dates and Times
> andEvents?
>
>
> > > 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.
> >
> > GREAT post.  YES.  This search for decision criteria between
> > "generic vs. specific" is exactly what we're grappling with,
> > privately, inside Netaccount where I work.
> >
> > Such a rule would not be trivial.  What is metadata in one context,
> > is data in another.  Here are my own thoughts.  Its all about
> > adoption. If you cannot replicate to 1 billion people in 12
> > months then you will be overgrown by faster-growing weeds:
> >
> > 1.  Human readability by domain experts as well as software
> specialist,
> > is a requirement.  This means, as a minimum you need the root and most
> > of the framework or hierarchy in the XML instance document to be
> > *sufficiently specific for human readability* by users directly in
> > the browser.
> >
> > 2.  Extensibility to be all-encompassing, but
> > 3.  Extensibility masked from view.  Like the sub sub menus in
> > Microsoft Word, you don't realize how much feature depth is in
> > the schema until you need it.
> >
> > Further befuddling the issue is the fact that what is necessary
> > in the class objects of GL software are not at all the same as
> > what is necesssary to include in the XML schema for transmitting it!
> > For instance you'd never have the accountname in every row of the
> > GL but it's a nice option for the XML schema in some scenarios.
> >
> > I am grateful to each of you for taking the time to discuss these
> > issues publicly.  Maybe there are some lurkers benefiting, also,
> >
> > Todd
> >
> > -----Original Message-----
> > From: Philip Goatly [mailto: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, [correction: should have been
> > EDIFACT 1001 document types -Todd]
> >
> > <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
> >
>
>
>
>
>
>