I agree. It is critical not to be too ambitious at present. I hope we can
take it in steps.
>
>
[Graham Moore] >>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.
I think that this wasn't intended to be so complicated. I think we are only
concerned at this stage with mapping an XML element node (not the subtree
and IDREFs, etc) onto a class or other 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.
So long as we keep it simple.
>>
>>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.
Originally (3) was chosen in the early namespace proposals using src= to
link to a schema. I used this (and found it useful) but it has been
superseded by a vacuum. [Because I move slowly JUMBO2 still uses remnants
of this mechanism such as:
<?jumbo:namespace ns="http://www.xml-cml.org"? java="jumbo.cml.*Node"?>
which binds <molecule> to jumbo.cml.MoleculeNode
At least it works.
(1) is what David Brownell offers in xml-ea1. When the elements hit the
client they are matched against a properties file and mapped onto classes.
I can be very happy with this, but everyone, including me, wants to see it
in XML. *** XSchema would be perfect for this, folks???
I also like this because the *client* can vary the application. This means
that is (hopefully) under their control. Thus if they get a <molecule>, one
person might want to send it to a database, another to synthesise it,
another to calculate something with it. So there has to be freedom at this
end.
(2) this suggests that the actual tool used to create the document
determines what tools are required to interpret it. This will lead to
private conventions. Sure, XML will have private conventions, but I suggest
we aim for interoperability at present.
>
>
>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.
i.e. (3) above. I assume that we consider that schemas could be packaged
alongside documents so that the actual instance doesn't need to be modified.
>
>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.
Yes. I hope this can be kept as simple as possible.
>
>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.
We clearly have to decide whether we can have a general approach or a
Java/IDL only approach at the start.
>
>>
>>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.
I think that there is great virtue in having a simple java-compatible
approach - there is such a lot to build on. If this leaves out more
powerful approaches I don't think this will be an immediate disaster (after
all we don't have anything yet !);
>
>>so the binding would be from
>>
>>element finder to finder.class, but finder.class would probably inherit
>from
>>the agent class.
We have a problem with inheritance because there is no universally agreed
method of defining it in SGML. To give an example of my own:
I have a class ArrayNode to support:
<array D:type="int">1 2 3 4 5</array>
And later I create:
<CML:bondArray D:type="int">1 2 1 1 2 3 2 1</CML:bondArray>
where jumbo.cml.BondArrayNode extends jumbo.xml.data.ArrayNode
But there is nothing in the SGML documents to enforce that bondArray can
inherit the attributes of array. I doubt we can solve this in the first pass.
>
>Perhaps the best thing is to clearly define the capability we are trying to
>develop.
Agreed, but... if we keep it very simple then we can make progress. If not,
we'll go into the quicksand. let's try to keep the concepts simple and
implementable.
>
>Bill
>
>>lets go do it..
Also agreed. There is clearly a considerable demand and no negative voices.
P
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg