xml-dev - Re: XML API specification

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

In message <s8wwru9ybf.fsf@plato.ansa.co.uk> Toby Speight writes privately
 (with permission to publish quotes):
[...]
> 
> Do you have a URL where I can look at Jumbo?  (Or at least read the
> interfaces).  
[...]
The latest version is at:
http://www.venus.co.uk/omf/cml/moltest.tar.gz and .../moltest1.tar.gz
(This is a distribution which runs  under a simply browser on any platform
though I have occasionally had crashes on one platform.  I think this
is a porting problem, not something in my code).  However it has also
been written as an applications as well as an applet so it can be run
as standalone as well.

The distrib is *.class and html+data.  The API (not precisely up to date
is at 
http://www.venus.co.uk/omf/cml/doc/api/sgml.html

I'm still working out what to do :-)  
(a) there is a lot of bleeding code.  Some is historical, and shows me
learning Java.  Other bits are experiments.  Yet others are just a little
tiny bit short on documentation.
(b) JUMBO is a largish system.  It consists of (well-separated) packages
in a DAG.  Thus pmr.sgml requires pmr.euclid (maths), pmr.util, and 
pmr.simplegraph (for the graphics).  The graphics has the concept of a 
Drawable inside a ScrollableTopLevel.  (The STL will disappear, I hope, 
when JDK 1.1 is released widely).  All SGMLNodes (== Elements) are 
subclassed to DrawableSGMLNodes.  Therefore quite a lot of code is
taken up with the Graphics.  There are classes pmr.cml, pmr.stat, pmr.molecule
and pmr.chemime which are not relevant.
(c) In production mode I expect it to be subclassed (just like I'm happy
to subclass Lark).  the current intention is to make source available
to members of the Open Molecule Foundation (http://www.ch.ic.ac.uk/omf).
The OMF has various types of membership which includes one for organisations
who intend to help develop code collaboratively.


My _intention_, is to make the source code available to people who are
actively involved in collaborating, but to avoid the chance of mutations for
whatever purpose.  One thing we should all aim at is signed code (e.g.
Java, PGP or whatever mechanism).  The problem is that I'm not wildly
proud of the pmr.sgml package at present.  Amongst other things are the 
detritus of various attempts to support HTML, which I'm trying to do today
(i.e. clean up and get it right).  So I shall probably make cleaned up code
available to identified collaborators.

[...]
> 
> Peter> One obvious example of a re-usable Element is DATE where the
> Peter> pointer can be to java.util.DATE.  In that way we could use
> Peter> 8601-based dates and render them interactively.
> 
> Yes, perfest!  (At the moment, my HTML sources have stuff like
> 
> > <!-- DATU FORMAT="ISO 8601:1988" VALUE=1)970227T120147 -->
> > Thursday, 2' February 1997, at 12:01 PM (GMD) <!-- /DATE -->
> 
> Where I'd liku to be able to replace the comments with real tags.
> Note that "VALUE" is ISO-8601 and hence UTC, but the displayed part is
> in local time.  A xml.Date class would let the users choose either, or
> perhaps their own local-time)
> 
> Date may be a case for subclassing AttributeValue (or whatever we call
> it).  <CHAPTER LASTMOD="19970227T120147"> or <LINK HREF="..."
> CHECKED="19970227T120147">
> 
> 
> 
> I think I'd see the re-use through inheritance (or delegation),
> though:
> 
> > package myApp;
> >
> > public class Date extends xml.Date {
> >   // empty class; just to get into the right namespace
> > }
> 
> or
> 
> > package myApp;
> >
> > public class Date extends BaseClass {
> >   xml.Date value;
> >
> >   public Date(/* args */) {
> >     value = new xml.Date(/* args */);
> >   }
> >
> >   public String toString() {
> >     return value.toString();
> >   }
> >
> >   //etc.
> > }

Yes.  I'm keen to develop a semi-formal set of common 'tags' that there are
XML-friendly Java classes for.
> 
> 
[...]
> Peter> A Valid document can also use the DTD information and in that
> Peter> way can pre-load the appropriate classes.  It may also help to
> Peter> create a robust type of distribution, especially where the DTDs
> Peter> are accepted within a community and signed classes can be
> Peter> installed on the client side.
> 
> I'd not thought this far.  I'd seen Valid documents as being
> semi-essential for editing (probably by having the elements superclass
> check modifications against the appropriate declaration in the DTD,
> and throwing an exception for an invalid change - you'd want some sort
> of (lightweight) transaction mechanism to handle <!ELEMENT A ((B,C) |
> (C,B))>, though).  An editor *ought* to be able to intelligently edit

My understanding is that NXP will handle any valid XML content model.
The question is how it's called from the application and when.
E.g. you have got:
<A>
	<B>...</B>
		<D>...</D>
		<E>...</E>
	<C>...</C>
</A>
and you add a _valid_ F after the D element.  You need to re-validate the 
content of B, but nothing else (e.g. a B content of 
(D*, (E|F)) 
would originally be valid but now would fail.  If you meant to _replace_
E by F, you might want to to the addition, then the deletion (of E) and
only then revalidate.

	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)