One definition of "syntax-neutral"

[Arofan Gregory <arofan.gregory@commerceone.com>]

Folks:

In the abstract, defining what we mean by "syntax-neutral" is indeed
difficult. In fact, we are working within a real set of parameters that can
be identified, and used to clarify the issue (I hope!)

(1) There will be more than one XML expression of any given business
document, for totally valid reasons that depend on implementation
considerations

(2) There may well be 1 or more EDI_type syntactic expressions of similar
messages

(3) UML (as has been stated) is not a sufficient way of capturing our data
models

(4) Our goal is to guarantee 100% reliability when transforming the same
business data from one syntax into another

(5) We have agreed to use an object model to describe the interactions,
relations, and extensibility of our core components


With this set of information, a few things become evident:

Distinctions between "attributes" and "elements", etc., are not really
meaningful. In order to guarantee that we can do 100% round-trip, we need to
simply agree on a set of name-value pairs that are related in such a way
that the grouping ("business object") can be usefully subclassed. Such
sub-classes will be described by the context in which they exist.

Becaue EDI and XML do validation in very different ways, and express
name-value pairs and hierarchy in different ways, it is not useful to argue
about how to translate from EDI syntax to XML syntax. This has been
identified, and several exercises in this area, both within the EDI world
and the XML world have demonstrated the futility of this approach satisfying
our needs across the board. Different approaches to this satisfy some user
segments, but not all!

Sequence is an aspect of syntax. Because sequence means very different
things in EDI and XML, it should not be an aspect of our descriptions of
core components. Similarly, optionality is a context-dependent aspect of
most name-value pairs associated with a core component.

We have come up with an interim approach to describing our core components.
This effort will continue, and hopefully bear fruit. My working definition
of what our published "core components" descriptions needs to include is as
follows:

- A set of related, common name-value pairs, with an indication of which are
required independent of context
- Definitions of the types of the values' data, expressed in terms of
also-defined core components
- Documentation describing the intent for use of the core component

Our definition of a core component is that data structure that exists
independent of context. If we can describe context, and describe a set of
components, then we have what we need.

Cheers,

Arofan Gregory