XML API specification

[Peter Murray-Rust]

Toby,
	Your suggestions are very similar to my own way of thinking, and
what is implemented (very crudely) in JUMBO.	

In message <s867zebhm4.fsf at plato.ansa.co.uk> Toby Speight writes:
[...]
> 
> I think IDL is a worthy target, and one we ought to have in mind.  But
> if speed of development and deployment are important (I think they
> are), a Java implementation makes a better "first-cut" prototype.

My gut feeling is that if we pursue a Java implementation then (apart
from the speed - which matters to me :-), we shall create a namespace
that is reusable by the IDL.  It may be that this has to be expanded 
but that's not a problem.

> 
> 
> Peter> The next question is the DTD.  I create a DTD class
> Peter> (e.g. HTMLDTD, CMLDTD) whose role is to provide the information
> Peter> from the DTD to the application.  I think this should be
> Peter> strightforward but I'm not clear enough to be sure what it
> Peter> should present.  At present mine simply contains GIs (someone
> Peter> suggested ElementType was a better name.)  It should also
> Peter> contain all the information in the normalised DTD,
> Peter> e.g. ContentModels, Attlists - what else is needed?
> 
> An application may want to get at entity definitions (of both types).
> Certainly, in writing an editor-type application (i.e. anything which
> takes XML input, and transforms it into some related XML or SGML
> output), there's a case for preserving entity references, rather than
> expanding them.

Totally accepted.  (The sort of thing we might want to do is to create a
'ThesisEditor' for chemistry.  This would have entities like &chapter1;
&tables1; &molecules; etc. and these should be relocatable as entities
as well as expanded subtrees.

> 
> 
> Something I'd like to do is to use Java as a kind of stylesheet
> mechanism, for interactive functionality not easy to do with DSSSL
> (which is somewhat paper-oriented).  For example, I'd like to be able
                     ^^^^^^^^^^^^^^^
Agreed.  
> to write documents like
> 
> > <?XML version="1.0">
> > <?XXX codebase="http://www.ansa.co.uk/whatever/classes"
> >        package="UK.co.ansa.tms" ?>
> > <!-- replace XXX above with the application's name -->
> >
> > <DOCUMENT>
> >  <TITLE>Picture Gallery</TITLE>
> >  <PICTURE title="My house" src="house.gif" thumb="thumbs/house.gif" />
> > </DOCUMENT>
> 
> and have the UK.co.ansa.tms.Picture class handle the rendering of the
> Picture element (I'd probably want a Default class to deal with
> elements that don't have corresponding classes - it would be tedious
> to write a class for every element).  Ignore the fact that most HTML

Exactly.  This is my DrawableElement class - it can be displayed, but
probably only offers a subtree, attlist, PCDATA children, etc. in a standard
fashion.

> browsers can do something similar - in fact, one reason I'd want this
> is to have the UK.co.ansa.tms.Picture class generate HTML markup like
> 
> <P><A HREF="house.gif" TITLE="My house"><IMG SRC="thumbs/house.gif"
> ALT="My house"></A>
> 
> This mechanism would enable anyone to write XML documents and the Java
> classes to render them, if the receiver has the basic parsing engine -
> you could provide the same document with different classes for
> printing, for HTML production, for interactive use, etc - or your
> Document class may have interactive options (menu items) for these
> things, calling the appropriate methods in the rendering classes.
> 
Exactly.  Your document is WF (it doesn't have a DOCTYPE) but the author
is saying "I have used a PICTURE tag.  I suggest you retrieve the 
Picture.class method and apply it.  Here's an address you might use
(www.ansa.co.uk...)."   The client doesn't need to know what a Picture
is.  IFF you agree with the client what a Picture is, the client might
say "thanks, but I already have client.Picture.class and I'll use that".
client.Picture might be a subclass of ansa.Picture.  This is the Java
equivalent of applying stylesheets at different times.

> 
> Here's a rough skeleton:
> 
> 
> > package UK.co.ansa.tms;
> >
> > public class Picture extends Default {
> >   // Default extends Component, for on-screen rendering
> >   private String title;
> >
> >   public Picture(xml.Element e) {
> >     // or nxp.Element, or lark.Element - haven't read enough detail
> >     //  on either, yet.  Can we have DTD information in e?
> >     // Create from the parse tree
> >     title = e.getAttribute("TITLE", true);
> >     // We grab attribute values in their "cooked" state, after
> >     // entity expansion
> >   }
> >
> >   public void draw() {
> >     // called by the parent element
> >   }
> >
> >   public void print() {
> >     // called by the parent element in response to user input
> >   }
> > }
> 
> 
> That's a very simple class with empty content model, container
> elements would in most cases implement draw(), print(), etc. by
> calling the same method on each of their contained elements.  An
> editing class, of course, may override routines for inserting or
> deleting content, or changing attributes.

This is exactly what JUMBO does - every Element has a
display(Graphics g)
toString()
toHTML()
toSGML()   // should be XML :-)
debug()
process()    // for delayed processing and caching of complex Elements
mouseUp(...)  etc.
addHelp()    // element-based help
drawIcon(...)   // icon-based recognition of element


One obvious example of a re-usable Element is DATE where the pointer can be
to java.util.DATE.  In that way we could use 8601-based dates and render them 
interactively.  Other examples would be things like the various image
types.

With a WF document you have to be careful that the client picks up
the right class and you have bound this via the APPLET mechanism.  With
a non-html-based document there needs to be some way of locating the 
methods precisely.  You also have to download information for each class
used.  You need to have a mechanism for loading the classes (i.e. 
something has to recognise the ElementType and download the class, maybe
creating an Element of this subclass - this is what JUMBO does.)

A Valid document can also use the DTD information and in that way can pre-load
the appropriate classes.  It may also help to create a robust type of
distribution, especially where the DTDs are accepted within a community
and signed classes can be installed on the client side.

[...]
> 
	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 at ic.ac.uk the following message;
unsubscribe xml-dev
List coordinator, Henry Rzepa (rzepa at ic.ac.uk)