This page maps the classes in the xg package to the Java interfaces in the Document Object Model (DOM). There is a reasonable correlation (it would be a worry if there wasn't!). Although xg currently supports only one of the DOM interfaces, it is intended to gradually implement them, and so slowly move towards DOM compliance (though full DOM compliance is not a strong goal and may never be achieved). Compliance to DOM is currently measured against the W3C Working Draft 18 March 1998.
DOM Level 1 Core
|
|
|
DOM | No direct equivalent - the closest being the xe package | Does not comply. |
DocumentContext | No direct equivalent | Does not comply. |
DocumentFragment | No direct equivalent | Does not comply. Potentially a useful addition for xe, in order to manipulate a selected portion of a document. |
Document | xg_Document | Does not comply. xg_Document does not create other objects. While this is easy enough to do for fixed types, in the xe environment, we want to be able to instantiate objects of other types - functionality which is implemented at the xe level. |
Node | xg_Node | Does not comply. Reasonably straightforward to implement, although xg_Node currently has no notion of 'current' node (and it sounds a rather untidy idea to have to do so). |
NodeIterator | No direct equivalent | Does not comply. |
TreeIterator | No direct equivalent | Does not comply. |
Attribute | xg_Attribute | Complies. Note, however, that the current xe implementation only creates attributes if they are explicitly specified (ie. defaults are not created as defined in the DTD). |
AttributeList | xg_AttList | Complies. |
Element | xg_Element | Does not comply. Reasonably straightforward mapping, although with what look like a few fiddly differences (eg. DOM setAttribute equates to xg_Element.addAttribute, but its behaviour if an attribute with this name already exists is different). xg_Element has no equivalent to the normalize method. |
Text | xg_Text | Does not comply. xg_Text has none of the DOM text manipulation functions, although these are easy to implement. |
Comment | xg_Comment | Does not comply. |
PI | xg_PI | Does not comply. |
DOM Level 1 XML
|
|
|
XMLNode | xg_Node | Does not comply. xg_Node currently lacks the ability to relate to parts of the DTD which relate to it, and also does not properly handle entity references. As above, xg_Node has no notion of 'current' node (and no wish to!). |
DocumentType | xg_Dtd | Does not comply. xg_Dtd is currently very simple, and is basically just a collection of its parts. In enhancing it to a level of reasonable usefulness, DOM compliance should be possible with little difficulty. |
ElementDefinition | xg_ElementDecl | Does not comply. While able to parse an element declaration, xg does not properly record the details of what was parsed. |
PCDATAToken | No direct equivalent | Does not comply.An equivalent needs to be added to xg in order to properly model element declarations, so DOM compliance could be added at this time. |
ElementToken | No direct equivalent | Does not comply. As for PCDATAToken |
ModelGroup | No direct equivalent | Does not comply. As for PCDATAToken |
AttributeDefinition | xg_AttDecl | Does not comply. xg_AttDecl is currently too simple for practical use. |
Notation | No direct equivalent | Does not comply. |
EntityDeclaration | xg_EntityDecl | Does not comply. |
EntityReference | xg_Reference | Does not comply. xg currently lacks proper support for references, including reference expansion. |
CDATASection | xg_Cdata | Does not comply. |