SOX: was Re: XML and Objects

[james anderson]

Peter Murray-Rust wrote:

a number of things re "XML and Objects", and closed with the suggestion that
it would be useful to focus the discussion on a set of questions.
Although I am not the right party to moderate (I'm working in a different
language, so the compatibility issues are academic), I would like to point to
several essential questions which I have not yet seen addressed in these
terms, as I would hope to see them resolved by whatever process develops.

> 
> ...
> 
> When a Document is created in the DOM the elements are of identical class
> (ElementNode?). SUN and JUMBO add a layer where subclassed objects are
> generated according to the elementName (and possibly other criteria). These
> objects may have further methods for display and non-display purposes. If
> we are going to have interoperable software then this is an area we should
> regularise ASAP.
> 
> [ contrast SUN and JUMBO2 ]
> ...
> 
> When I create MoleculeNode I endow it with JUMBO methods and therefore it
> doesn't interoperate with SUN. I would be delighted to agree publicly on
> how to do this now. If we leave it we shall be too late and we shall have
> applications-specific )and possibly platform-specific element-oriented
> programming. This would be very sad.

There are several issues here
1. How to identify which behavior to associate with the element identifier?
2. How to identify which storage structure to associate with the element identifier?
3. Which behavior (DOM and/or application object model) is associated?
4. How is the behavior implemented?
5. How is the storage structure implemented?

1: 
I have found it straight-forward and sufficient to identify the element type
through the simple mechanism of class-name lookup. Note that I am working in
CLOS, which has a MOP adequate to this purpose. Pre-namespaces I had tended
towards an index of dtd/document specific class definitions. With the advent
of qualified names, and with the presumption, that definitions used in one
document for a unique name should agree with those used for the same name in
another document, the per-document qualification is superfluous.

In the cl-xml implementation the element identifier simply denotes a symbol.
An optional attribute permits instance specific variation. The symbol, in
turn, names a DEFCLASS'd class. There is a safety check to ensure that the
proper interface is supported, but the basic rule is: if the symbol names a
known class, then the element is intended to encode the named class. no
tables. no props files. 

In a CLOS environment, this depends only on a mechanism which identifies lisp
packages with xml namespaces. For java, by analogy, a mechanism which
identified java packages with xml namespaces would suffice.

2:
Since, for my purposes, type and storage are both identified with the class in
CLOS, the storage structure is identified through a mechanism identical to
that used for type - class name lookup. Because of my approach to 4 and 5,
this simplification is reasonable.

3:
This is a much stickier problem. As I have followed the discussion, most of it
has implied that one and the same instance serves to model both the object
which was encoded in XML and the application's view of the related (or even
identical) object. I recall only one note which suggested an alternative, that
a standard element class model the element specific behavior distinct from
application specific classes. I would second this notion. In other words, the
XML instance is a model of the application instance for the purpose of
encoding it in a serial stream.

4:
Issue 3 carries over to the approach to 4 and 5. That is, in most cases the
implementation implied by the discussion to date is that inheritance be used
to achieve an identity between the element and the application instance. In
the alternative note, I recall the suggestion being that a delegation relation
extend from the element instance to the application instance.
As I have come to understand XML as an encoding standard and not a modeling
standard, these suggestions surprise me. Of the three possible forms

  a. identity between application and encoding instances
  b. encoding instance delegates to application
  c. application instance delegates to encoding

the latter makes more sense for complex applications. For example, aspects of
behavior may not coincide or may vary depending on the encoded content. This
means, that a more complex translation process may be necessary in order to
decode to the application model than would be appropriate to model in the DOM
or its descendants. In some cases, I have found it advantageous to accomplish
the translation functionally.

In CLOS, the method definition mechanism offers the advantage that it is
possible to specialize on multiple arguments. This means that it is possible
to define a "translation application" which comprises an application instance
and a collection methods which are specialized on the combination of element
class and translation application. I have found this degree of specificity to
be useful when decoding complex data structures.

In the encoding direction, on the other hand method 'c' can be specified
fairly directly in the class declaration.

5:
For reasons analogous to 3, I find it sufficient to leave untouched the
DOM(-equivalent) storage model which is sufficient for element instances.
Application specific storage requirements are handled in the autonomous
application specific instances.


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)