xml-dev - Re: XML API specification

[Toby Speight <tms@ansa.co.uk>]

-----BEGIN PGP SIGNED MESSAGE-----

Peter> Peter Murray-Rust <URL:mailto:Peter@ursus.demon.co.uk>
Tim> Tim Bray

Tim> I would propose seriously that Java be the basis of the first cut
Tim> at an API spec; it is really very pleasingly clean, and also has
Tim> the virtue that ideas can be tested more or less instantly
Tim> because there's running parser code to graft them onto.


>>>>> In article <4028@ursus.demon.co.uk>, Peter wrote:

Peter> I'd agree with this.  I think there is a case for a completely
Peter> basic parser which builds from Lark/NXP and explores the basic
Peter> issues that PhaseI raises.

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.


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.


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
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
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.


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.



-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQB1AwUBMxVzCedsuUurvcRtAQG4nwL7BXUR9R7UXfZZxTlb2AP6/vQjD4AdESiS
YDyQEHZM4scfDwjkl2Y1RayRa4wHan3cmUBoRK+ooA87BCoVjsAO8Owphw6POYmK
M7s96TG9CzEfxLPeu9Ju4UnBqVtiT2kS
=A2u1
-----END PGP SIGNATURE-----

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)