[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: One definition of "syntax-neutral"
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
Powered by eList eXpress LLC