[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]
Powered by eList eXpress LLC