xml-dev - Re: Xapi-J: an architectural detail

[Richard Light <richard@light.demon.co.uk>]

In message <33E502A7.80A66A68@datachannel.com>, John Tigue
<john@datachannel.com> writes
>
>An XML document can be represented as a tree. In an XML document object
>model there are things which are containers (e.g. a document is a
>container and so is an element) and also things which are the content of
>a container (e.g. a chunk of text is a content or even a element can be,
>in the case of one element within another). To model these there are the
>IContainer and IContent interfaces. The full source follows:
>
>public interface IContainer
>     {
>     public Enumeration getContents();
>     public void insertContent( IContent aContent, IContent
>preceedingContent );
>     public void appendContent( IContent aContent );
>     public void removeContent( IContent aContent );
>     }
>
>public interface IContent
>     {
>     public void setParent( IContainer aContainer );
>     public IContainer getParent();
>     public String getData();
>     }

These interfaces are mirrored in the SGML/XML Property Set.  In that,
everything is a 'node', each with its own name and a set of properties.
One of those properties is 'subnode' - having a subnode property makes a
node, de facto, into a Container in your terminology.  The complete XML
document can be represented as a 'grove' (tree structure) of these
nodes.

The parent-child relationship between elements of the XML document is
more specific than this.  The full grove includes things like the DTD
and processing instructions, which are nodes in the grove structure but
do not exhibit 'parent-child' relationships to anything else.

Nodes have some 'intrinsic properties', which apply whatever their
particular type might be.  (Again, this mirrors your thinking very
closely.)  These intrinsic properties are:

object Node
  property ClassNm  ; the name of the node's class
  property GrovRoot ; the root of the grove of which the node forms a
part
  property SunPNs   ; the names of all the subnode properties exhibited
by the node
  property AllPNs   ; the names of all the properties exhibited by the
node
  property ChildPN  ; the name of the children property, when this class
of node has children 
  property DataPN   : the data property name (i.e. 'char' or 'string'),
when this class of node contains data
  property DSepPN   ; the data separator property name
  property Parent   ; the node's parent
  property TreeRoot ; the root of the parent-children tree [not the same
as the 'grove root']
  property Origin   ; the node that that this node as one of its subnode
properties
  property OTSRelPN ; the origin-to-subnode relationship property name

I've given the full set of intrinsic node properties, really just to
point out that all of this modeling has already been done before.  Much
of it is too detailed (and perhaps one level too abstract) to apply to
Xapi-J.  However, I'm concerned that Xapi-J developers shouldn't just
ignore the SGML property set and invent their own version.

Expressing the only intrinsic property (parent) that is relevant to this
discussion leads to:

public interface XMLnode
        {
        public XMLnode parent();
        }

We could add in a couple of extra intrinsic properties, so you can get
to the grove root and its origin from any node:

public interface XMLnode
        {
        public XMLnode parent();
        public XMLnode grovroot();
        public XMLnode origin();
        }

I don't think we need separate IContainer and IContent interfaces -
what's wrong with just INode (or XMLnode, as I have it)?

>These interfaces only express the methods for navigating a tree. A
>particular class of objects would need to have some more methods to be
>interesting. For example, the interface for an element is IElement. The
>full source follows:
>
>public interface IElement extends IContent, IContainer
>    {
>     public String getType();
>     public void setType( String aType );
>     public void addAttribute( String name, String value );
>     public void removeAttribute( String name );
>     public IAttribute getAttribute( String attributeName );
>     public java.util.Enumeration getAttributes();
>     }
>
>The above states that an IElement can be a container and/or a content
>and also has some other methods particular to being an element. So
>although IElement does not directly have a method called getContents(),
>it gets the method from its superinterface IContainer.

We can do the same thing here:

public interface XMLelement extends XMLnode
        {
        public String gi();
        public void setType( String aType );
        public void addAttribute( String name, String value );
        public void removeAttribute( String name );
        public XMLattribute getAttribute( String attributeName );
        public XMLattlist atts();
        }

Notice that I've left the middle four declarations more or less
unchanged, for the following reason:  

There is definitely a useful distinction here, between those things
which are _properties_ of a node within an XML document, like the GI of
an element or its list of declared attributes, and _operations_ which
the API lets you carry out on that node.

The SGML/XML property set is entirely about the properties of an
existing instance.  It provides no framework or precedent for API
commands which _alter_ that instance, like SetType (which assigns or
changes the GI of an element).  There, we are rather more on our own!

I'm not sure if the Java API provides for a more elegant way of
specifying a property than the one I've dreamt up - if it does, we
should use it.

Hope this helps.

Richard Light
SGML and Museum Information Consultancy
richard@light.demon.co.uk
3 Midfields Walk 
Burgess Hill
West Sussex RH15 8JA
U.K.
tel. (44) 1444 232067

xml-dev: A list for W3C XML Developers
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To unsubscribe, send to majordomo@ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa@ic.ac.uk)