[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] SOX: was Re: XML and Objects
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@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|