|  | <?xml version="1.0" encoding="utf-8"?> | 
|  | <?xml-stylesheet type="text/xsl" href="../../../wtp.xsl"?> | 
|  | <html> | 
|  | <head> | 
|  | <meta name="root" content="../../../../" /> | 
|  | <title>XML Component Overview</title> | 
|  | </head> | 
|  | <body> | 
|  |  | 
|  | <h1>XML Component</h1> | 
|  |  | 
|  | <p>Last modified March 27, 2005</p> | 
|  |  | 
|  | <p> | 
|  | <i> | 
|  | [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.] | 
|  | </i> | 
|  | </p> | 
|  |  | 
|  | <h2>XML UI</h2> | 
|  | <p> | 
|  | There is a UI Component to XML. The UI component has little | 
|  | API and .... | 
|  | </p> | 
|  | <h3>Editor related IDs</h3> | 
|  | <p> | 
|  | Some of these IDs are literally used in WTP 1.0, some are | 
|  | considered reserved for future use. | 
|  | </p> | 
|  | <h4>Source page</h4> | 
|  | <h4>Context menus [etc]</h4> | 
|  |  | 
|  |  | 
|  | <h2>XML Core</h2> | 
|  | <p> | 
|  | The more substantial contribution of XML is its core APIs. | 
|  | </p> | 
|  | <h3>XML Catalog and XML Resolution</h3> | 
|  | <p>[Craig to provide]</p> | 
|  | <h3>DOM Parser</h3> | 
|  | <p> | 
|  | 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. | 
|  | </p> | 
|  | <p> | 
|  | 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. | 
|  | </p> | 
|  | <p> | 
|  | In addition to the w3c standard base DOM API methods, our | 
|  | DOM provides | 
|  | <ul> | 
|  | <li> | 
|  | Each Node implements SSE's IIndexedRegion so its | 
|  | expected it can report back its exact source | 
|  | locations. | 
|  | </li> | 
|  | <li> | 
|  | There are some "read-only" APIs that allow nodes be | 
|  | made read-only with respect to their data, | 
|  | attributes or children. | 
|  | </li> | 
|  | <li> | 
|  | 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. | 
|  | </li> | 
|  | <li> | 
|  | 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. | 
|  | </li> | 
|  | </ul> | 
|  | </p> | 
|  | <h3>Content types and encoding</h3> | 
|  | <h3>Content Models</h3> | 
|  | <h3>Formatting</h3> | 
|  | <h3>List of StructuredDocument regions</h3> | 
|  | <h3>List of Partition Types</h3> | 
|  | <h3>Extension Points</h3> | 
|  | <h4>Comment Elements</h4> | 
|  | <h4>document types</h4> | 
|  | </body> | 
|  | </html> |