xml-dev - REPOST: XML Java API-an idea

[clloyd@gorge.net (Chris Lloyd)]

This is a repost because some of the original post was clipped.

I'm just entering this thread so I don't know what solutions have been discussed. 
There is already an API to draw from in the DSSSL spec and a definition of the 
SGML property set which gives us a common language to work from. 
The problem is that an XML API to a grove should be simple with a 
small interface and should leverage the object-oriented power and syntax of Java.

Personally, when working with groves I find some abstractions very useful in an API. 
I would rather have an API based on iterators than one based on a set of navigation function calls.  I'm talking about navigating the grove rather than building the grove. An iterator API would be extremely simple, well abstracted and more inline with patterns of C++ and Java programming than the SDQL API found in DSSSL. They could also maintain an adherence to the syntax of the SGML property set.

Here is an example although my naming syntax probably does not correspond to 
the SGML property set here.

// Assuming we have a object provided by the parser that is a grove, 
instantiate an iterator and navigate to the first element that is a TITLE tag

// A Factory is an object that defines what SGML/XML constructs the iterator 
knows how to iterate. It provides the grove iterator with a different node 
iterator for each property node that it knows how to walk.

ForwardGroveIterator XMLIter(OurGrove, XMLPropertySetFactory(), StartNodePropertyHandle);

While(XMLIter++ != XMLIter.end())
{
	XMLBaseProperty Prop = XMLIter.Object(); // in C++ we would use the dereference operator like this XMLBaseProperty Prop = *XMLIter;
	If (Prop.GetClass() == Element.Class) // is this an element?
	{
		Element aElement = Prop; // lets convert the property from a base class object to it's concrete class 
		// Now we have an element object and can call all it's member functions
		if (Element.GetIdent() == String("TITLE"))
			break;
	}
}

// OK lets instantiate a new iterator to walk back up to the root of the grove
// use the copy constructor to produce a reverse iterator from our forward iterator
ReverseGroveIterator XMLReverseIter(XMLIter);

While(XMLReverseIter++ != XMLReverseIter.end())
{
	// do stuff here
}


The navigation itself is not the same as defined in SDQL but the property set 
could be made to conform to the SGML property set. This might offer a compromise. 

The factory concept is very powerful because extending an iterator is as simple 
as adding a new factory class and a nodeiterator class for each new property 
being added to the grove. If someone wanted to inherit from the XML property set 
and put metadata in their grove, they could easily extend the functionality 
of the base iterators to support their new properties. 
Because the iterator class has a small interface, It's easy to plug and play 
new iterators into existing code. You can read more about iterators and 
factories in Design Patterns, Addison Wesley, Gamma, Helm, Johnson, Vlissides.

Once we have the appropriate iterators then we can create an API of Functions 
and Algorthimns maybe based on SDQL that can do higher-level operations like this

// Find the first parent object that is an element
Algorithmn::find( ReverseIter, classid<Element>()); // C++ sytax with templates
Algorithmn::find( ReverseIter, classid(ELEMENT)); // Java sytax without templates

// Find the first object that is an element and whose name is TITLE
if (Algorithmn::find( ReverseIter, AND(classid<Element>(), name("TITLE"))))
{
	Element aElementFound = *ReverseIter; // get the element and use it
}

Why we need iterators
1.) Iterators hide the details of how a grove is actually linked together, whether is memory or in a object database, etc.. 
2.) Iterators have the same iterface regardless of the types of properties in the grove
3.) Iterators are extensible and can provide read-only functionality as well as read-write functionality
4.) Iterators are a well know and accepted design pattern and are 

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)