[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XObjects (was TLAa was SOX)

• From: David Brownell <db@E...>
• To: xml-dev@i...
• Date: Thu, 08 Oct 1998 10:09:04 -0700

I believe we need two modes of document creation:  "empty",
so they can be constructed programmatically; and "parsed",
where they're built from a stream of XML text.

I'm posting this note (1) to point out the need for those two
creation modes, (2) to suggest an API for the former, and also
(3) to point out why the latter is harder than has yet been
noted on this list.  (Sorry for the length of that part!)

Consider an API like this for the former:

    // like SAX ParserFactory, but using standard
    // factory naming conventions "createXXX"

    public class XmlDocumentFactory {
	/**
	 * Creates an empty XML Document using a DOM
	 * implementation that's administratively specified.
	 * That is conventionally the system property <TBS>.
	 */
	public static Document createDocument ();

	/**
	 * Creates an empty XML Document using a DOM
	 * implementation that's identified by the parameter.
	 */
	public static Document createDocument (String impl);
}

Such a document could of course be configured to know about
particular element-->object bindings.  The implementation of
Document would need a null constructor, period.


Re the latter, I agree that a "Builder" API with "build"
method makes much sense ... in fact, Sun's current (and
changeable!) APIs adopt that exact naming convention.

The structure of such a builder is a tricky problem.  I
think of it as a module that's separate from the DOM and
separate from the (SAX) parser, but might need to be coupled
to either or to both.  Reason:  neither API is sufficient
for supporting all DOM semantics without some more coupling.

Example: fully conforming to DOM means having access to more
information than SAX exposes.  Which attributes were defaulted?
What are the default values of attributes?  Where do entities
start/stop?  What parsed entities exist?  And more.  While
it's easy to write a builder that takes a SAX event stream
and a document, then populates a DOM Document from it, it can't
possibly offer full DOM semantics.  (Then there's efficiency...)

Example:  fully conforming to DOM means feeding more data
into the DOM implementation than the DOM APIs allow!  How
would you construct a DocumentType object?  Or reset an
attribute to its default value?  Etc.

How important do folk think it is to be able to mix'n'match
parsers and DOM implementations?

- Dave

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

• Follow-Ups:
  • Re: XObjects (was TLAa was SOX)
    • From: Peter Murray-Rust <peter@u...>

• References:
  • Re: XObjects (was TLAa was SOX)
    • From: "Bill la Forge" <b.laforge@j...>

• Prev by Date: Re: More namespaces perversion
• Next by Date: Re: More namespaces perversion
• Previous by thread: Re: XObjects (was TLAa was SOX)
• Next by thread: Re: XObjects (was TLAa was SOX)
• Index(es):
  • Date
  • Thread