State of browsers/JUMBO

[Peter Murray-Rust]

At 12:23 02/09/98 +0100, Michael Kay wrote:
>
>Some observations:
>
>- I tried (more than once) downloading Jumbo and exploring
>what it could do for me. I didn't make much progress.
>There's clearly an enormous amount of functionality there,
>but I found it very hard to know where to start. I've had

Fully accepted. This is true of most enthusiast software. I had expected
JUMBO to be overtaken.  I need it for my own purposes and offer it to others.
[A new version should be out tonight - but it's still 'alpha'].

>the same experience with downloads of other XML software
>(most recently XML Toolkit), and I dare say others have had
>the same experience with my own SAXON library.
>
>- I suspect that as a community the thing we are desperately
>lacking is a commonly understood architecture. We're all

Certainly. The architecture that JUMBO needs is the ability to
render/process/validate on a per-object basis. This is also what XXX does.
Steve Withal uses verify() [I think] while I use what I think is a similar
function processXML(). Something that runs code on an endElement event to:
	- customise/transform the internals
	- verify (possibly includes DTD-like validation)
	- render in interactive form.
For chemistry I have to have processing for data types (a la DCD) and
specials such as <molecule>

>writing bits of code that do useful things with XML, but we
>don't have a clear vision as to what the total set of
>capabilities should look like or how its components should
>relate to each other. I think this is why it's hard to take
>something like Jumbo and discover quickly what pieces of the
>jigsaw it supplies.

I'd be delighted if there were others who have this need and we can work
out an API. This is the most obvious area for me - and I would assume many
others. Or is everyone quite happy to wait for stylesheets - in which case
I am in a minority as stylesheets and ECMAScript won't do much useful for
chemistry.
>
>- Having all these people produce free software is great,
>but the downside is that most of it was written to satisfy
>the intellectual creativity and/or parochial application
>requirements of the individual author, which means that the
>boring parts of software development, like working out who
>the users are and writing good task-oriented documentation
>to meet their needs, have been sadly neglected. Perhaps this
>is why real product developers like Microsoft seem to be
>slow. Fred Brooks, I recall, said that writing a one-off
>program is one-tenth the effort of producing a software
>product that does the same thing.

No question. But the enthusiast community has - on occasion - shown it can
be done. I don't see why it couldn't be attempted here. 
>
>Regarding Simon's essay, I don't share his pessimism. I
>don't personally regard client-side browser support for XML
>as particularly urgent, I'm quite happy to do rendition
>server-side either on demand, or in many cases at site

If 'rendition' means rendering for humans to read then we can use PDF. The
points of client side functionality for me are that:
	- we can carry out operations without troubling the server. Examples are
interactive graphics (my background is molecular graphics). Holding the
displayTree in the server for processing is untenable for many operations.
And my graphics have to be intelligent enough to be coupled to a data model
	- we may not even *have* a server (some people will interact with XML
documents disconnected from a remote server)
	- we may wish to interact with the local resources

I still feel that XML is suited to many operations other than sending
human-readable non-interactive text over the WWW. For example I could see
it as a way of building a MOO (or - more ambitiously - interactive games)
in a platform-independent manner. You can't do this well in HTML. 

>generation time. One reason is that the client-side model
>(along with XLink and XSL) seems to assume that the web of
>XML documents has the same topology as the web presented to
>the user, which I think grossly underexploits the ability of
>XML to separate the information structure from the user
>view. I think a much more valuable development would be the
>integration of XML with database technology. (And in
>practice, I'm actually using XML mainly for "EDI" style
>applications. )

Surely one thing we need is form-like data entry implemented on the client
side. [Using XML to generate HTML forms surely misses the point.] So I have
been experimenting with client-side data authoring tools. XML has great
potential as an authoring tool for specialist or complex domains - again I
see little evidence that people are addressing this.

I shall keep appealing for enthusiasts and we'll see what turns up. Doesn't
need many. Maybe they don't yet come to XML-DEV...

	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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)