[
Lists Home |
Date Index |
Thread Index
]
- From: "Bill la Forge" <b.laforge@jxml.com>
- To: "Peter Murray-Rust" <peter@ursus.demon.co.uk>, <xml-dev@ic.ac.uk>
- Date: Thu, 1 Oct 1998 08:16:19 -0400
From: Peter Murray-Rust <peter@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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)
|