SOX - Overview, Issues, Implementati

[Bill la Forge]

Graham,

I think we are going to need to take this more slowly, especially as
we may be dealing with a new paradigm.


>1) Overview
>
>To standardised the procedure of associating functionality with a
seriliased
>object structure.


I don't see this at all. I am not at all interested in trying to figure out
how
to represent arbitrary grapghs of objects in XML.

For me, the documents are primary. They are internalized as trees with
secondary connections (IDREF's) and tertiary connections (links between
documents) which are handled differently from the primary connections
between nodes in the DOM. (Though right now, my emphasis is on a
fourth connection, between an object in the tree and an application object.

My focus is on internalizing a set of interconnected documents, performing
some processing, and then updating selected documents.

>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.


Lets look at what is being exchanged--the documents. so the first
level of agreement needs to be on how the binding should be specified
in the document, when that is appropriate, and when such information
can be ignored.

The next area of importance is the the shape of the domBuilder. Is it
a standalone process (like coins)? or is it a class. If the latter, then
what needs to be passed to it? What is the configuration information?

A third area would be the api needed on the application objects, if any.

A fourth area would be the data model for connecting XML and
application objects.

But key here is figuring out what this thing is and what kind of
interfaces it might support (and why).


>2.2) The binding information
>

Some of this looks like Microsoft terminology. A bit out of my scope.
I think potentially there needs to be connections between an XML
and the system it is running on, but I hope the document itself
doesn't need to carry vendor-specific information!!! SOX may
need some partitioning here. some developers may be sticking
with the Sun JDK, while others are Microsoft all the way.

Could we push this down to a lower level? I think it belongs, but
nowhere near the top. A different appendix for each vendor-
specific approach, perhaps.

>  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.

And when you start using connection objects (I'm calling them wrappers right
now)
to move the data from the DOM into application-specific objects, you need
to specify this connection object in the bindings as well.

In a more general case, lets say you have a set of bindings, but within that
set, there are different kinds of bindings supported. Now we can allow
for wrappers, OLE servers, etc.

>
>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.


First, I'm confused by the word functional above. If it changes the meaning,
of what was said, then I'm at a loss.

By having different kinds of bindings, we can support a mix of models on
an element-by-element basis. This is what coins does now.

>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.


I think the words matter here. The term serialize is not generally
restricted
to DOM trees. I'd prefer to say externalize, transport, internalize. But
parse
is clearer than internalize.

>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.


Well, I'd rather say that the binding depends on the current use being
made of the document. If it is being transcribed into an email, then
the bindings would be a bit different. If it is being processed for
billing information, the bindings are again quite different.

>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.


Transport is a most exciting aspect, but only one aspect. The
document is likely itself a wrapper for other documents. Further, a
transported document itself is likely connected (linked to) other
documents, forming a web of documents which provide the
operating context for the transported document.

>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.


Might be better to focus on the shape first, before trying to attach
interfaces
to it. Is a bindings document the way to go? What about a data model for
connecting a particular ml to a set of application documents?

Perhaps the best thing is to clearly define the capability we are trying to
develop.

Bill

>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)