(XML-DEV) SOX - Overview, Issues, Implementation

[Bill la Forge]

From: Peter Murray-Rust <peter at ursus.demon.co.uk>


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

Or onto a pair of objects, perhaps? I.E. An application object and a
wrapper which implements the w3c Dom Element class.

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


Only if each application has its own XSchema document for each use of
each ml. I used to agree with this, but I now believe it should be a
different document.

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

1 & 3 look solid, with 1 being able to override 3.


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

I'm still clueless on sgml properties. Anyone have a book to
recommend? Something which assumes no knowledge of SGML?

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

I think now that there should be provision for vendor-specifics.

In 1, the bindings are local to the application, separate from the document,
and can be vendor specific.

In 3, there is a build-in dependency already, as the classes (or the
particular
version compatible with the data) may be tied to the vendor.

So I've toggled on this one. But I'd really like the vendor-specifics
pushed down to individual element considerations. Say we have a Bindings
markup language which is universal, but which suports vendor-specific
mappings at the element level.

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

I've been playing with wrappers/connectors in Coins. The wrappers implement
Element and are part of the DOM tree. And they do not need inheritence. Each
wrapper holds an application object which is instantiated based on the
application bindings (based on element name). (This allows for wrapper
reuse.)

The application objects are free to use inheritence. They may or may not be
able
to participate in the DOM tree, depending on their constructor--If they have
a constructor which takes an Element parameter, then they are given the
wrapper
which holds the reference to that application object. (Basically, we're
talking
about a peer relationship in this case.)


I had at one point seriously considered aggregation for Elements and instead
decided on pairs of objects with either one-way or two-way connections. It
seems powerful enough. Enables application inheritence while avoiding
Element inheritence.

>>>lets go do it..
>
>Also agreed. There is clearly a considerable demand and no negative voices.


Sounds like fun to me.

Bill


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)