was Re: XML and Objects

[Bill la Forge]

From: Peter Murray-Rust <peter at ursus.demon.co.uk>
>To contrast SUN and JUMBO2.
>
>SUN has an XmlDocumentBuilder which is passed a list of props. These come
>from a *.props file where elementNames are mapped onto classes. The
>XmlDocumentBuilder (I don't have the code) creates new Instances of each
>subclassed object when SAX processes the event. Additional element-specific
>operations can be added through a doneParse(URI) method which a subclass
>can override.
>
>JUMBO (which was started pre-DOM and old namespaces) uses a PI to map
>namespaces onto code - a legacy of the src= attribute. It's not pretty but
>it works. It has a method processXML() which is called from SAX when an
>endElement event is encountered. [I suspect it's very similar to
doneParse().]
>
>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.


Coins uses an XML Bindings file to define the mapping. I just completed the
documentation for Bindings, including examples (if not the entire web page):
        http://www.jxml.com/coins/index.html

>Here are some general points which I think we need to address now.
>
> - how do we map elements onto classes. Property file? Regexps in PIs?
>Stylesheets? or a mixture

or XML? I would argue that the mapping should be separate, except when
doing object serialization

> - what are the *non-graphics* methods for an element , e.g.:
> doneParse()/processXML()
> isValid() [i.e. non-XML validation - type, values, etc.]

The SAX interface, DocumentHandler, works rather well for much of this.

> write() - recreate XML or other formats

If a document carries a reference to its source, and that source is
writable,
then UPDATE is vital--I explored this in coins v0.

> - what are the graphics methods
> onClick(count)
> redraw()/resize() etc.


I've been looking at graphical elements of late and this looks unnecessary.
Just use wrapper elements. But the key here is to support references between
the wrapped gui objects.

>Rather than try to list more I'd like to see coordinated discussion a la
>SAX. In that case David Megginson offered to take XML-DEVers through a
>series of questions which he then collated and re-offered. The initial pass
>took only a calendar month (including year-end). But he worked VERY hard.
>
>Can we have volunteers for this? It's one of the most critical aspects of
>XML at present that is not covered by other WG programs (if this is covered
>by DOM 2.0 can we wait for this? An XML-DEV API could be a valuable
>creation anyway).


I would be delighted to participate, though I should likely not be the one
to
chair this.

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)