xml-dev - Re: Xapi-J: an architectural detail (long)

[Peter@ursus.demon.co.uk (Peter Murray-Rust)]

John,
Thanks very much for this - including keeping the momentum of this effort.
I encourage other memebrs of this list to react to this posting - John
has obviously worked very hard at this.

In message <33E407E3.37404793@datachannel.com> john@datachannel.com (John Tigue) writes:
[...]
> 
> Folks don't really have a problem grasping the XML object model:
> 
> To get a new XML processor object instance:
>      xml.XMLProcessor xmler = new xml.XMLProcessor();
> 
> To have a processor read a document:
>      xml.IDocument aDocument = xmler.readXML( someInfoSource );
> 
> To get the root of a document:
>     xml.IElement anElement = aDocument.getRoot();
> 
> To get an element's attributes:
>      java.util.Enumeration someAttributes = anElement.getAttributes();
> 
> That's easy to understand. It is a very simple object model
> which can be mapped onto many of the current XML processors without
> requiring major rewrites.

I follow all this.  Can we also go one step further and say how we get
the children of an Element.  I am assuming also that (say) the DTD is 
not a child of root in this model - do you have proposals for all this?
If so, please post them :-) so we can get it finished - we keep going round
and round on this ...

> 
[...]
> 
> (I have tested that Xapi-J can be implemented on top of msxml. I have

Excellent!  What are your thoughts about NXP and Lark?

[...]
> 
> The execution sequence looks like:
> 1. The factory is set via XMLProcessor.setIXMLProcessorFactory().
> 2. Later, a "new XMLProcessor()" happens.
> 3. In the constructor the factory is asked to return an IXMLProcessor.
> 4. The IXMLProcessor object is assigned to the field "implementation".
> 5. Later, a "readXML()" call happens.
> 6. In readXML(), the XMLProcessor object, acting as a proxy, passes
>           the request onto its IXMLProcessor and then,
> 7. The XMLProcessor object returns whatever is returned to it from its
>           IXMLProcessor. I.e. class IXMLProcessor is the real worker.
> 
> So the phrase "Xapi-J contains no XML processor" could more precisely be
> 
> stated as: Xapi-J does contain a class XMLProcessor but it does not
> contain an implementation of the interface IXMLProcessor which is the
> real worker/processor in the Xapi-J architecture.
> 
> The above is a convoluted dance but to the developer who is simply using
> 
> an Xapi-J compliant XML processor it looks really simple on the outside.
> 
> (For a very similar "design patter" see java.net.Socket et al.) And only
> one
> API has to be learned to work with any Xapi-J compliant processor.

I think I have followed John's logic and proposal, and suggest that we take
this as a concrete proposal.  Since it's only likely to be used by a smallish
number of people, its apparent complexity is acceptable.  For example, JUMBO
is able to use more than one parser, but I have to delve into each one to
see how to extract the correct aprts.  This would make it easier overall.

Assuming we accept this I'd like us also to tackle the question of Nodes, 
Elements, etc. Until this is done it's difficult to build application 
software with interchangeable parts. For example, there is a lot of generic
stuff (see my posting on whitespace) that an XML application (?processor)
has to implement, and hopefully we can isolate and standardise on that.

Once again, thanks John.

	P.


-- 
Peter Murray-Rust, domestic net connection
Virtual School of Molecular Sciences
http://www.vsms.nottingham.ac.uk/

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)