JUMBO

[Peter Murray-Rust]

Here is a summary of some progress with JUMBO.  My intention is to have
it all tidied by Barcelona.

JUMBO has its own parser (Mus Michaelis algorithm), but can use NXP via
a command-line switch (and will hopefully grok Lark in the same way in a
few hours).  This means that it gives a visual rendering of current XML files
assuming they parse with NXP or Lark.

Errors.  NXP does not throw catchable errors but (I think) produces a null 
output stream.  Lark requires JUMBO to handle doSyntaxError().  JUMBO has no
heuristics to turn a broken WF-document into something valid.  If the parser
writer wishes to pass JUMBO an Esis (NXP) or a Tree (Element*, Lark) then
JUMBO will treat that as valid if it isn't thrown an error.  Without being
thrown an error, or being passed an error flag, it's not easy for JUMBO
to know it's got one. 

If you think this list has become slightly sleepy, and you haven't been 
reading the WG discussions, you can always ask: 'How do we treat parse
errors?'.  The general feeling is it's an implementation matter, so we
have to have a means of passing it to applications.

JUMBO has been rewritten internally to remove the grotesque architecture
that I started with.  This has not added functionality, but I am at least
prepared to show some code in public.  JUMBO is now in a state where it is 
possible to use it to convert legacy files to WF-XML.  Some limited
validation of content model and attributes are also possible but they are
not automatically DTD-driven, because DTDs have a poor API for programming.

JUMBO implements XML-LINK as far as I understand it.  I have NOT done:
	- spans and '..' because I am unsure of the semantics
	- GROUP/DOCUMENT - because I can't see *what* to implement
	- some of the trickier bits of negative addressing in PREVIOUS, etc.
		because I'm waiting till that's stable and everyone actually
		agrees one its operation

Most XML-LINK implementation is application-dependent.  *I AM MISSING ANY 
EXAMPLES OF XML-LINK other than my own.*  I can implement my own, but they
are probably JUMBO-specific.  

JUMBO has primitive editing facilities, especially for WF-docs.  I have not
done attribute editing, because programming little boxes in Java is horrible.
In principle JUMBO can validate content models if it uses NXP's code, but I
need to discuss this with Norbert.

JUMBO is aimed at supporting *INFORMATION COMPONENTS* rather than traditional
DTDs (which are not much use in technical and scientific subjects).  An
information component is an Element linked to code for displaying, processing, 
etc. (I use Java).  JUMBO can manage many of the common information components
such as hypertext, images, tables, graphs, bibliography, etc.  If you are
interesting in learning more about this, I am launching an 8-week virtual
course on this at:
	http://www.vsms.nottingham.ac.uk/vsms/java
and a CDROM with the new JUMBO, examples, API, etc. will be included in the
course materials.  No previous knowledge of XML and Java is assumed, but
you need programming skills.  All necessary information is one the WWW pages.

	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)