RE: Comments on ebXML Core Components forms

["Stuart Campbell" <scampbell@cmass.co.uk>]

Bob

I'm the guilty party who put forward these suggestions to Martin so I'd like
to fill you in / comment....

I've no problem with notes and examples imbedded in 'Description',
***Ah, fatal flaw.  All we are trying to achieve via XML tagging and the
conceptually bounded identification of data falls down in an instant
heap...description is for descriptions, examples for examples.  This then
allows you to reuse the data systematically - perhaps presentation through a
table or perhaps more excitingly through extracting the example to generate
dummy data for XML messages.  All concepts should be separated and the only
one I allow to break this rule (that I've come across) is date time.
Whatever you do, don't start mixing them up from the start since there is no
going back...

and so see no need for separate Notes and Examples subcomponents.  I do have
a
problem with mandatory examples - 1) Examples are not appropriate to some
things I might register.
***I would like to see the exceptions that break the rule.  In practice I
have found none at the leaf levels (e.g. Organisation.Name) and none at
components (Organisation) one above them however it does become pretty
impossible for message-like top components.  The reason I put forward this
suggestion is from extensive experience of EDIFACT and recent large scale
XML business library experience.  EDIFACT effectively has no examples in the
standards that why they are so hard to fathom.  EDIFACTs subsets do have
examples and that what makes them friendly.  After all look at the EDI MIGs
we use - they all contain examples.  For elements which have code lists,
examples aren't so necessary (they are just extracts - all though good
examples from such list inform, help and allow e.g. example XML generation)
however for free text elements without codes they are invaluable.  Obviously
examples don't apply to other data types except string although typically
values also can help.


I'll give a 'maybe' to synonyms - 1) en:name and fr:name are not synonyms.
2) Many (most? all?) synonyms turn out to be 'almost synonyms'.
It is perhaps better to treat all 'synonyms' as 'almost synonyms' and define
them independently as subclasses of the same parent class.
Of course, I wouldn't have any 'almost synonyms' in the Core Components, as
these are the definitions upon which the 'off-by' are founded.
***Yes, I agree.  I find synonyms invariably equally misleading.  Infact the
point I was making to martin was that do not set in stone the fact that only
names and descriptions can be associated with different languages...others,
such as synonyms, could be as well


PS:Another thing I forgot to mention to Martin was to ensure that the
language possibilities don't just follow English, French, German etc but
also allow for Real English, Real French and the others - EN-US, EN-AU etc
:-)   From EDIFACT we all know that shares - stock - inventory are not
necessarily related concepts!


STUART CAMPBELL, Operations Manager CMASS
CMASS : Critical Mass in Electronic Commerce

          E: scampbell@cmass.co.uk
          W: www.stuartcampbell.co.uk
          W: www.cmass.be
UK        T: +44 1270 254019   F: +44 7971 121013
Belgium   T: +322 7179390      F: +322 7215400
          M: +44 7970 429251