'XML browser'

In message <v02140b00af12e6848280@[208.203.149.72]> murray@spyglass.com (Murray Altheim) writes:
> Peter Flynn <pflynn@curia.ucc.ie> writes:
> >It has always amazed me that the math|phys|bio|chem communities have
> >been so neglected by browser makers. There must be tens of thousands
> >who would pay for a seriously good scientific browser.
> 
> Unfortunately, you are correct. And also unfortunately, tens of thousands
> is not considered a market by either Netscape, Microsoft, or Spyglass.
> These guys are in it for the tens of millions, or non. The best hope is to
> provide extra services via plugins. One of the nice ideas around XML is
> that it's conceivable that an XML application could be public domain,
> Java-based (ie., interoperable), simple and lightweight.
> 
> Murray

I'd like to suggest features of 'an XML browser' and a 'generic XML
application'; this also picks up the themes of 'killer apps' and 
'marketing' which have been raised by Jon and others.  I appreciate that
implementation may be slightly off-topic but I have personally found
that it's very valuable to have an idea of what the final product (e.g.
XML is going to be used for and what it will look like).

Jon outlines a number of areas where XML has the potential to make a 
big impact within a domain which is not well served by HTML at the moment.
airline scheduling, circuits, and molecular science (i.e. CML) are good 
examples.  I have no doubt that in (say) 2-3 years' time some of these
disciplines may have enough vision, will and resources to create:
	an XML-based DTD
	authoring tools, protocols, legacy translators, etc.
	domain-specific semantics
	client-side rendering and processing technology.
However XML faces a major challenge here in that each discipline has to
discover the value of XML for themselves.  And, unless we help, they'll
do it piecemeal.  (That is what I have done for CML, in Java, including:
	- an XML parser (happily to be junked now that lark, NXP, etc.
		are here).
	- a dynamic DTD loader (see below)
	- a generic TOC tool
	- a generic search/addressing (a la CoST)
	- a generic glossary management tool
The domain-specific material (renderers, legacy converters, and 
postprocessors are, of course, specific to molecularscience, but a great
deal is general.)

If this is what XML achieves it will be marvellous, but it may still be
very fragmented and it will depend on the specific disciplines.  It
would be a killer app, it will be a fairly quiet revolution.  What I'd
like to suggest is something that will have the same impact as HTTP/HTML
did, and to create _generic_ XML applications.

XML can catch the imagination of the world in several ways:
	- transporting content that cannot be done at present
	- transporting structure that cannot be done at present.
	- searching and analysing structured documents
	- providing generic client-side technology.
	- managing hyperdocuments

I will stick with the first four.

The content that *is* managed at present is text and images.  To make
an impact here we need to have something that:
	- everybody knows about and would like to transmit
	- can be rendered easily.
At present the obvious candidates in my area are:
	- parsable math (not TeX)
	- structured graphics (e.g. VRML, CGM)
and for general interest I would add:
	- numeric data (HTML TABLE is _not_ adequate)
	- money
	- people

I would like to suggest that the XML community build a generic tool that
is capable of a wide variety of applications in the last three areas.
It requires a simple extensible DTD, generic XML tools (which all XML 
apps will require - parsers, TOCs, etc) and a generic renderer.  (This
may also involve some extensibility, perhaps using Java).

In designing CML I needed to create a generic technical DTD and have been
using this for the last 18 months.  Originally called XML (for eXperimental
Markup Language) it's now called TecML (Technical Markup Language - PLEASE
don't tell me there's a name collision!) and is at:
http://www.venus.co.uk/omf/cml/doc/dtd/
It is a meta DTD and is capable of holding a very wide range of applications
including:
	- an organisation chart
	- stock market prices
Its components are:
	XLIST - a generic container for anything.  This allows complex data
		structures since it can contain itself and any other 
		Element (content = ANY; I'll defend this later!)
	XVAR - a generic data primitive holding strings, numbers, dates,
		etc.
	ARRAY - an array of data primitives 
	XNOTATION - for NOTATION (e.g. accepted standards, TeX, CGM, HDF
		etc.)
	PERSON - a generic person with attributes (address, e-mail, etc)
	XADDR - a real-life address
	XHTML - an HTML container (%body.content).
	BIB - a citation
	TERMENTRY - a glossary entry.  (Most semantics are resolved through
		glossaries).

With this one can tackle a very large number of applications.  (For example
I have done the org chart, and could manage the stock prices in a few
days.)  It works through having a cascading series of attributes:
	BUILTIN - which is hardcoded into the DTDs (and particularly the
		added DTDs like CML/MOL)
	DICTNAME - reference to a glossary entry
	CONVENTION - resolves which glossary is required
so that currency might look like:
<XVAR TITLE="Price" DICTNAME="DailyRange03" CONVENTION="FTSE-LONDON" 
FUZZY="Range" UNITS="USDollars">1.379 1.382</XVAR>

Because the renderer is generic it can render this without knowing what
the domain is :-) and if the user wishes to interpret the information
she follows the hyperlinks (XMLLINKs ;-) to the glossary.  A single
tool covers a variety of applications.

I am sure we shall need a generic meta-DTD of this sort and generic tools.
In any case the components have to be built for _all_ applications.  I 
belive in the virtual collaborative ethic and am happy to share what I've
done with others if it helps.  (I reiterate that there is no chemistry
involved!).

My current environment is Java and I believe we have to have this for a 
killer app.  The great advantage is that it can co-exist with existing
browsers and therefore a lot of the work is partly done.  (Otherwise
a lot of basic tools have to be written)
A rough shopping list would be:
	- XML parser (we can tick this)
	- generic TOC tool (I have written one, but it needs overhauling)
	- addressing tool within a document (a la TEI/XMLLINK spec)
	- dynamic class loader for additional DTD specific Elements/classes
	- XMLLINK resolution to external documents (not necessary for 
		first killer app??)
	- SGML-independent rendering tools (graphs, clickable diagrams,
		hypertables, mailers, etc., etc.
	- integration of this approach with current/future browser 
		technology (i.e. what is the best way of distributing this
		killer app.  Is it always an APPLET - I think not).

I hope this doesn't take us too much off-topic, but I think it helps to
keep us close to the core of the language.

	P.


-- 
Peter Murray-Rust, (domestic net connection)
Virtual School of Molecular Sciences, Nottingham University, UK
http://www.ccc.nottingham.ac.uk/~pazpmr/

Received on Tuesday, 28 January 1997 05:48:59 UTC