SOX: was Re: XML and Objects

[Peter Murray-Rust]

I'd very much like us to explore how we can produce an interface/protocol
for element/object-oriented programming. This has been catalysed by the
early release of the SUN code (many thanks) and the discussion over the
last week.

As noted, the DOM provides an excellent basis for this but it doesn't go
far enough. Since SUN, Steve Withall, coins, JUMBO, et al. have all gone a
little way down this road it seems critical that we investigate what common
ground we have before we have needless bifurcation. 

I'll use the code SOX for this idea (unless people prefer Simple
Element-oriented XML). This is a very brief outline.

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. 

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.

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
	- what are the *non-graphics* methods for an element , e.g.:
		doneParse()/processXML()
		isValid() [i.e. non-XML validation - type, values, etc.]
		write() - recreate XML or other formats
	- what are the graphics methods
		onClick(count)
		redraw()/resize() etc.

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

	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

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)