At 21:46 01/10/98 +0200, james anderson wrote:
>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
I don't necessarily think we are limited to Java, though I think that will
be the main thrust. From my perspective the client gets at XML element and
needs to do something with it. There is no requirement that a particular
element is always treated by the same code, any more than (say) there is a
universal HTML client.
>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.
>
>
>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
Remember that the client simply has an element name to start with. They
have to be able to identify a class (regardless of language to associate
with it). This could be a planet-wide piece of Java (e.g.
org.xmlcml.MoleculeNode.class for element ("http://www.xml-cml.org", Foo))
or it could be a locally mounted 'helper' application - the element is
mapped to C:\bin\rasmol.exe. Either way we need a mapping.
Some people have suggested mappings are very difficult. I'm more optimistic!
>
>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.
I suspect that in the first instance the storage will depend on the
implementation of the processing code. That may be able to offer options
(e.g. persistence) but people like me just want to start with something
that works for simple cases and build up.
>
>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.
I am not quite sure I understand this, but I would agree that the XML is an
abstraction of the instance as far as possible. In my own field (molecules)
I expect radically different implementations to view and process the same
instance since people have different views. (e.g. benzene rings can be
represented with single/double bonds or with aromatic bonds). I think this
is more than just a style issue.
>
>4:
[beyond me :-)]
>
>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.
For many objects I would wish storage which was different from the DOM or
SAX representation (e.g. for efficiency of storage). Thus a molecule with
10^5 nodes is very inefficient if stored as nodes, but can reasonably be
input and output as such. But I may have missed your point :-)
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