Last modified March 27, 2005

[This document is a work in progress. It is an attempt to capture the key concepts of the WTP XML Component. Note that the concepts presented here may differ from what is found in the currently released code. This document describes the architecture, or "end goal", of the component. Once this document is finalized, the intent is to bring the code and its specs into line with this document.]

There is a UI Component to XML. The UI component has little API and ....

Some of these IDs are literally used in WTP 1.0, some are considered reserved for future use.

Source page

Context menus [etc]

The more substantial contribution of XML is its core APIs.

[Craig to provide]

This DOM parser complies in general terms to the Base DOM APIs Version 2.0. Plus it has a number of other features that go beyond the w3c specified APIs.

One thing that's very important to note, though, it that this DOM Parser is specifically made to work with ill formed text. This is important for "editing" sorts of function since the DOM is often invalid while typing. We use heuristics to do the best job of parsing it to what we think is expected. Clients need to be aware however, this makes this DOM Parser inappropriate to use for other things, since most specs call for the parser to fail on ill formed text.

In addition to the w3c standard base DOM API methods, our DOM provides

• Each Node implements SSE's IIndexedRegion so its expected it can report back its exact source locations.
• There are some "read-only" APIs that allow nodes be made read-only with respect to their data, attributes or children.
• The Nodes implement SSE's INodeNotifier so INodeAdapters can be added to specific Nodes, so the adapters can be notified when ever there is a change.
• We have introduced the concept of a "comment element". In many development situations, clients want to introduce a "custom element" which in other contexts are treated as a simple comment.

Comment Elements

document types