xml-dev - Re: RFC: Simple XML Event-Based API for Java

[Peter Murray-Rust <peter@ursus.demon.co.uk>]

At 11:35 18/12/97 -0000, Michael Kay wrote:
>I like the way this discussion is going. I don't want to be on anyone's
>critical path, but I'll be trying out these interfaces (as an "application
>writer") if I can find the time.

This is really great Michael.

My vision of (at least one role of) the interface is precisely what you
describe. An intelligent, but ignorant Java/XML application programmer.
<QUOTE>
<BOOK PAGE="36" PUBLSHER="IOP" DATE="1973">A Random Walk in Science</BOOK>
<SCIENTIST NAME="Luria" SUBJECT="Biology" STATUS="Great">
I don't know what to assume...
</SCIENTIST>
<SCIENTIST NAME="Szilard" SUBJECT="Physics" STATUS="Great">
You may assume  infinite ignorance and unlimited intelligence
</SCIENTIST>
</QUOTE>

>I've written a very simple application using AElfred: a converter from an
>XML-based encoding of genealogical data back to the "standard"
>GEDCOM encoding. 

This counts :-)

(The converter the other way was in Visual Basic,
>I will probably rewrite it in Java now I'm getting the hang of it.) It is
>beautifully concise, just 17 lines of code apart from the boilerplate
>which was copied straight from one of the AElfred sample apps,
>and will be even simpler with the proposed revisions to the
>interface.

This is exactly what we are after. The idea that we can develop an
application in a few lines is one of the beauties of XML. After all, we are
likely to get a lot more converts if they can write their app in half a
page. The boilerplate lends itself to GUI tools (e.g. presenting the
programmer with a dozen boxes to fill in for doEntity, etc.)

>
>To do anything more interesting with the data (i.e. anything that is not
>a single-pass operation) I need a tree representation. Yes, I don't
>want to build my own. The DOM seems to be the right solution for 
>this. The idea of having a choice of parsers with the same event
>interface, and a choice of tree-builders that build the same DOM
>interface using any of the parsers, is very appealing.

Absolutely. JUMBO is essentially a tree-based tool and I expect it to
either implement the DOM or to simply hand over large chunk of current code
to better written stuff for tree management.

As you've probably seen, the Java SwingSet has a Tree tool, which comes
with an example. The major time taking is simply to find one's way around
the documentation.  I would have liked to use it for JUMBO and hacked a
simple example, but I need quite a lot of functionality for each displayed
node and I haven't yet found out how to do that (basically I need a
miniPanel for each node).
>
>(What I haven't really worked out yet, and would appreciate advice
>on, is how to turn the XML objects into a set of genealogical
>objects, with methods like getFather(), getMother(), getSpouses(). Do
>I need to build a separate tree with the data organised differently,
>or should I write methods/functions that operate on the nodes in 
>the XML tree? I guess the chemists must have similar problems.)

I nearly replied to your earlier posting, but was too busy.

Any pure tree is extremely easy to represent in XML. So, if you simply want
to trace an ancestor tree (i.e. two parents, 4 grand parents, etc.) this is
trivial. If some happen to be identical you can use entities to normalise
the data or hyperlinks. E.g. your father's father's father could be your
mother's mother's father in most countries (cousin marriage). I can display
an animal taxonomy using nothing more than XML and standard JUMBO. 

The difficulty comes when the graph has cycles. I am not an expert
genealogist, but most 'family trees' seem to me to be Directed Acyclic
Graphs (DAGs) where the arcs are isParentOf(); and is directional.  DAGs
are common in areas like multiple inheritance graphs (C++), multiple
ontological views, etc. I would hope that some standard ways of
representing DAGs might come out of XML and that there would be standard
viewing tools.

Note that the use of ID/IDREF may introduce additional complexity.
Personally I am not clear on the value of IDREF over XLL - it's not trivial
to support in a browser and I doubt that JUMBO will do it.

If we include marriage or other descriptions of human liaison we have a
different type of link. This results in a complex structure, which I would
use XLL to represent.  I'd value views on this, because we shall be
encountering XLL on this list from time to time :-)

One approach is to regard all nodes as disjoint, and to create every
relationship in a separate database. A fictitious family might look like:

<!ATTLIST RELATIONSHIP xml:link CDATA #FIXED "EXTENDED">
<!ATTLIST LOCATOR xml:link CDATA #FIXED "LOCATOR">

<LIST ID="people">
<PERSON ID="liz">Elizabeth</PERSON>
<PERSON ID="phil">Philip</PERSON>
<PERSON ID="chas">Charles</PERSON>
<PERSON ID="di" STATUS="deceased">Diana</PERSON>
<PERSON ID="cpb">Camilla</PERSON>
</LIST>

<LIST id="relationships">
<RELATIONSHIP ID="couple1>
<LOCATOR HREF="#ID(liz)" ROLE="wife">
<LOCATOR HREF="#ID(phil)" ROLE="hubby">
</RELATIONSHIP>
<RELATIONSHIP>
<LOCATOR HREF="#ID(chas)" ROLE="wife">
<LOCATOR HREF="#ID(di)" ROLE="hubby">
</RELATIONSHIP>
<RELATIONSHIP>
<LOCATOR HREF="#ID(chas)" ROLE="son">
<LOCATOR HREF="#ID(couple1)" ROLE="parents">
</RELATIONSHIP>
<RELATIONSHIP>
<LOCATOR HREF="#ID(chas)" ROLE="lover" BEHAVIOR="clandestine">
<LOCATOR HREF="#ID(cpb)" ROLE="lover">
</RELATIONSHIP>
</LIST>

To represent this structure prettily, and to navigate it usefully, is
almost certainly application-dependent. There are some nice graph layout
tools but they cannot render every application in a meaningful manner.
(Some might even be molecules :-)
>
>The other thing I need, which has not really been fully addressed,
>is access to the DTD. (Not for this application, which I am doing
>just as a learning exercise, but for my real job.) I think we need
>some kind of extension to the DOM to provide this.

I await other comments, but my expectations is that the DOM will actively
deal with this. Experts, please?

	P.


Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

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