OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-core message

[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?


Hi Phil

Comments in ***s

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 ?
***I agree, but equally know the subjective nature of all of this - one mans
element is anothers attribute discussion!  EDIFACT takes the approach of
being as generic as possible and adding qualifier after qualifer (not always
called quaifiers) to try to further precise a generic value and uses code
lists to assist in managing this.  Dispersed semantics is an australian term
that comes to mind.  We all know this is a possible approach in XML as well.
The way i try to design XML/object structures is by acting on a rule of
thumb that only value elements can have code lists.  For example country is
a basic library component whose only value content can be a country, as such
it is reasonable to associate this with a country code list.  On the other
hand origination.country and destination.country simply resuse the same
country class and thus a composite component of
<country_type><type/><country/></country_type> is not warranted

  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.
***At design time in either case you need to change the schema.  In one case
add a new element in another i add a new code.  The schema can use external
entities in either case to do this either as a library code list file or a
library element component.  Thus no real hardship difference in either case.
At implementation time, if you implement either you need to make a new
mapping of one form or the other so if not really a qestion of more
difficult or not - simply that many tools now are focused on eg elements and
are less capable in other areas such as codes.  Same argument as
element/attributes in DTDs - first attributes were well respected since
tools did stuff like auto drop down list generation but now we all
understand this is just a feature of the tool and not the syntax

Dont know if this helps you though



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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC