SOX - Overview, Issues, Implementati

[Graham Moore]

I've just tried to organsie a few thoughts on the SOX issue; to clarify it 
for myself and maybe others. Perhaps we can take some of these headings or 
rename them, but I think we need some focus for the dicussion. This is a 
very important issue. We do not want to get this wrong.

I've tried to highlight issues and alternatives, and where I feel strongly 
espress my opinion.

So, here is an

1) Overview of what it is we are trying to achieve
2) Issues with Naming and Defining the association
3) Implementation
4) Potential Use - With Examples
5) where it can go

1) Overview

To standardised the procedure of associating functionality with a seriliased 
object structure.

Traditionally, objects have had the abiliy to serialise and unserialise 
themselves. The difference now is that  with self describing serialised 
object structures the potential exists to associate different functional 
views with the same data object.

The way in which

  a) the binding between the functionality ( functional object ?)  and the 
object data is specified.

  b) this is implemented

are the problems we are trying to solve.

2) Issues

2.1) Naming and Defining the association

Who should name the functional assocition?

 1) the receiving application could name the binding
 2) the sending application could name the binding
 3) the serialised instance could contain the binding information

So do we need to agree on an interface for the domBuilder to allow all of 
these and other possibilities? Probably yes.

2.2) The binding information

  The binding could be a java package / OLE server. tThe naming works well 
with both

   oleServerName.automationObjectName

   javaPackageName.ClassName

   XXXX.ZZZZZZ in the general case.

   Does a package binding then imply a simple element to class mapping

   e.g.

  <menu>
  ......
  </menu>

  mapping to menu.class within package myobjects

  A more refined step would be to specify all the bindings in an XML file.

 <FNelemmap elemName="menu" fnName="myobjects.menu">

  So we could have a package binding and then optionally an instance map as 
well.

3) Implementation

I think the main question to answer is do we have an inheritance or 
delegation model. As others and myself have advocated, a delegation model is 
more powerful and a superset of inheritance. If we were all working using 
object lisp like systems then delegation would be the choice. However, most 
people are not and delegation does not integrate seamlessly with java or 
automation architectures. But it could be done.

my opinion is that the functional binding specification should be written to 
allow for the definition of delegation structures with an additional 
'strict' option - the dispatch order cannot be changed - to allow it to be 
implemented as an inheritance structure.

4) Potential Use & Examples

1) The 'coins' use of XML and the 'run' method on the root object 
demonstrates the use of XML as a transport and execution mechanism for 
agents. This is a specialisation of the general pattern of serialise, 
transport, rebuild and run. In this case the XML is the serialised form of 
the application.

an example would be

   <finder id="1">
     <odbcConnection>dynamciHTMLServer</odbcConnection>
     <reportTo><ip>x.x.x.x</ip><port>5656</port>
     <cond>where name='index.html'</cond>
   </finder>

so the binding would be from

element finder to finder.class, but finder.class would probably inherit from 
the agent class.

Calling 'run' would delegate the call to the finder class that would then 
execute. In the above case the agent would retreive a doc from a odbc 
database and send it or an error message to the 'reportTo' port.

2) Alternatively, the functionality is combined at the destination to 
provide a set of objects that are used the by the current application. 
Consider a TP system

<trans>
  <basket>
     <item>...</item>
     <item>...</item>
     <item>...</item>
     <item>...</item>
     <item>...</item>
  </basket>
</trans>

The TP system receivces this, binds the appropriate functionality and then 
asks the transaction

trans.calculateTotal();
trans.calculateOfferReduction();
trans.CommitToDataBase(ODBCConnection);
trans.CommitToDataBase(OO DB name);
etc
etc.

5) Where it can go..

Focus and contributions, organisation of thoughts; perhaps along some of the 
lines outlined above.

A simple first step would be to define a domBuilder interface that could 
support a variety of ways forward. Perhaps as these are developed it will 
become clearer where to focus our efforts.

lets go do it..

graham.

gdm at dpsl.co.uk





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)