Re: Core Component Analysis - SWIFT's Comments

[Martin Bryan <mtbryan@sgml.u-net.com>]

William Kammerer wrote

>I think Phil is also uncomfortable with the notion of big, long tag
names built up from semantic units - like those suggested by SWIFT's
Jacques Littré: BirthDate, DeathDate, and IncorporationDate.  He'd
probably have the same objection to using BSR semantic units as tags:
AccountsPayables.Contact.Person.Name, Approval.DateAndTime or
Consignee.Location.City.Name. But the intent of these techniques based
on ISO 11179 is to give us decomposable names - the same purpose served
by  EDIFACT qualifiers.

I've just prepared a short paper entitled The Role of Semantics in
E-business (http://www.sgml.u-net.com/relationships.html) in which I explain
the difference between dictionary-based semantics and classification-based
semantics. This paper also explains that role properties actually describe
relationships between message components and the business process that is
identified by the message type property of the overall message container. It
goes on to explain why hiearchical structures simplify the understanding to
the relationships between message components. In doing so I hope that I have
shed some light on Philip Goatley's comments on:

>  In the world of international trade there is no complete definition and
all
> of us are modeling in  conditions of uncertainty. It follows that should a
> new party be required in a transaction, for a particular industry then if
> the 'new party' is defined as a class - in XML we have to change the
> schema/DTD or whatever.
>
> This means users of this message must upgrade to maintain compatibility.
>
> If one uses a coding system for the parties then one just adds to the code
> list - for those who need the new party and everyone stays happy.

By decoupling the definition of roles from the definition of the information
required to perform those roles we can simplify the naming of information
components in business messages. By using hierarchies to express
relationships we can use inheritance to determine the unique set of
properties that identifies instances of a particular information component
(e.g. the address of the purchaser from the address of the supplier).

Phil goes on to state:

> Just one question - how are we gonig to deal with many to many
relationships
> within an XML hieararchy. I am sufficiently old/mature to remember the
> problem  we had with such things in Hierarchical databases and the factors
> which led to Relational Databases where relationships are made at run
time.
> With XML we seem to be back to hierarchies which may lead to similar
> difficulties.

As my paper explains, providing these relationships are expressed in terms
of siblings of the same parent then the relationships between siblings allow
us to determine information relating to many-to-many relationships.
Describing many-to-many relationships between information components that
are not siblings, or do not have parents that are siblings, is the real
problem. This is why ebXML needs a constraint language to describe none
hierarchical constraints.

Martin Bryan

Martin Bryan