Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Xapi-J: an architectural detail
 In message <33E502A7.80A66A68@d...>, John Tigue <john@d...> 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@l... 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@i... the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@i...) 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
