OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: XObjects (was TLAa was SOX)

[ Lists Home | Date Index | Thread Index ]
  • From: "Bill la Forge" <b.laforge@jxml.com>
  • To: <tyler@infinet.com>, "Graham Moore" <graham.moore@dpsl.co.uk>, <peter@ursus.demon.co.uk>
  • Date: Thu, 8 Oct 1998 09:54:36 -0400

>I like XObjects. XObjects IS what we are doing. Its like CLOS - common lisp
>object system.

XObjects captures it perfectly.

>anyway interfaces.........
>>        public interface Bindings
>>        {
>>                        public org.w3c.dom.Document
>>                convert(org.xml.sax.InputSource inputSource)
>>                       throws SAXException;
>>        }
>i think the above is at the right level. Is this part of a domBuilder
>if so should 'convert' be 'build'
>        public interface domBuilder
>        {
>                        public org.w3c.dom.Document
> build(org.xml.sax.InputSource inputSource)
>                        throws SAXException;
>          public org.w3c.dom.Document  build(org.xml.sax.InputSource
>inputSource, org.w3c.dom.Document mappingDOM)
>                        throws SAXException;
>          etc.
>        }
>The second prototype is an example of how generic binding types might be
>specified. The mappingDOM contains information regarding the instantiation
>of the DOM from the inputSource.

One area I always need advice on is the names of things. I'm happy with
build and DomBuilder. (I'm thinking Java, so I've capitalized the interface

When a DomBuilder object is built from a BindingsML document, the DomBuilder
object is the root element of the DOM tree (as defined by BindingsML).
Lets say we have an object, domBuilderBuilder, itself a DomBuilder object,
which builds DomBuilder objects from BindingsML documents:

    Element root=myMLBindingsDoc.getDocumentElement();
    DomBuilder myMLBuilder=(DomBuilder)root;
    Document applicationDoc=myMLBuilder.build(applicationInputSource);

The above code then achieves the same effect as the second build method.
Likely best handled as a static method.

So I think we could have only one method in the DomBuilder interface. And
it may be best to have that interface NOT extend any other interface.
That way we can simply subclass existing systems, which already build
DOM trees from XML documents.

For example, the Docuverse class com.docuverse.dom.DOM has
a openDocument which does a build. So we could subclass it and
get immediate conformance. (With only a little care needed to
handle the exceptions properly.)


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)


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS