Position paper for XMSF Workshop
August 2002

George S. Carson
GSC Associates
5272 Redman Road
Las Cruces, NM 88011


This short position paper describes our background and perspective on the problems of distributed M&S and gives some feedback on the Technical Opportunities Workshop White Paper.

Background and experience

Here is a very brief summary of applicable portions of my company's background to help you understand the heritage of  some ideas I propose for your consideration:

  1. Real time and distributed systems, including simulations and models.

  2. Internet appliances including large scale, real-time cooperative systems.

  3. Standards and consortia, including over 20 years developing International Standards ( http://www.iso.org/ )

  4. Universal Plug and Play ( http://www.upnp.org/

Key challenges

The Technical Opportunities Workshop White Paper listed the "key challenges for XMSF". Based on our background and experience here is our list of key challenges and possible solutions:

Key challenge

Possible solution

Semantics not syntax

While XML is an element of the solution at the syntax level, the focus must be top-down and driven by semantics not syntax.  The SEDRIS family of emerging International Standards ( http://www.sedris.org/wg8home/index.htm ) are a key element of the solution.
Human readable yet compact A high-level description of the syntax of messages in a format such as XML can be "compiled" into a very compact "on-the-wire" coded representation. Coded PDUs can be "un-compiled" back into human readable formats such as XML.
Communication No single solution is appropriate. The focus should be in Internet technologies and not just "the web". IP, UDP and many other protocols are key parts of a family of solutions.  Message based paradigms as well as procedural paradigms are very appropriate.


The Technical Opportunities Workshop White Paper listed sets of "considerations" from which various "functional requirements" are derived. Based on our background and experience here are some observations:



3.1.1 Data Representation
A further requirement is that the data representation not only be suitable for machine processing,
but also amenable to being read by humans.

Not a requirement. A real requirement would be that data can be represented in a form suitable for reading by a human being.
3.1.2 Service Description We believe this does not go far enough. Services should be described and invoked in a location-independent manner.
3.1.3 Graphical User Interface Description
The end aim of a GUI description is to define a consistent look and feel across operating systems.
An equally reasonable requirement is that the unique HCI capabilities of each platform be used to best advantage.
3.1.6 Transactions
The usual paradigm that has been used for some time is that of the 2-phase commit. Unfortunately,
this approach when applied to the Internet suffers from latency and heavy resource utilization.
The statement depends on how 2-phase commit is implemented. What if "the transaction is moved to the data"?
3.1.7 Ontologies
A subsequent requirement is that of consensual common meaning.
We agree. This is why we list "semantics not syntax" as a key challenge. The standards community has a great deal of experience in specifying semantics.
3.1.9 Search Engines This seems off the mark to us. Directory services, however, seem a key requirement - translating names into other information, such as addesses,
4.1.1 End-to-end QoS None of this paragraph is actually requirements. The statements "Delivery is defined as correct for reliable data if the data does not contain detectable errors, and for best-effort data if the specified loss rate and latency is not exceeded" seem bizarre. Why do latency and error rates not apply in both cases? Also distributions, not just averages, are important for all parameters.
5.1.2 Authoritative Representations
XMSF will provide mechanisms and formats for mapping existing authoritative representations
between existing formats.
Not sure what this means.
5.1.3 Composability
XMSF must support multiple levels of model and component composability including enabling
reasoning about the suitability of components for composition.
Why is this not best left as a manual function?