JUMBO Bugs, Features, etc.
1998-01-27
Timescales
When new languages are developed it is important to have prototype implementations
and this provided some of my motivation. Therefore JUMBO tracks the emerging
XML specs (at present XML, XLL and XSL) as fast as they are developed.
In general these will change quite rapidly during periods of intense discussion
and decision on the XML-SIG and XML-WG. The price is sometimes that early
decisions take time to remove. XML was originally case-insensitive and
JUMBO was designed on this basis; when it changed it took time to locate
and alter the various places where insensitivity might be hidden. Similarly
the XLL spec changed a lot in mid-1997 and some of the features have not
been implemented completely. In some cases features of the languages have
no obvious place in generic software. So, at present, xml:space,
xml:link="extended" and "group" and some other features
have no special code in JUMBO.
Unimplemented aspects or personal views of the spec
XML
Many of the features below are unimportant in rendering the output for
parsers but matter when JUMBO is used as an authoring/editing system. Some
await a consistent (or at least stable) interface with DTD information
from various parsers (e.g. ATTLISTs).
-
no special support for encodings or internationalization or xml:lang. JUMBO
will rely on a combination of parser-writers and Java to provide the necessary
support. For example isValidName() really requires a central XML library.
-
no support for NOTATION. I am not quite sure what this does or how to implement
it in practice.
-
error-handling. This is very difficult to manage generically. Jumbo will
catch parser-writers' Exceptions and (probably) revert to its previous
state (i.e. it is Draconian).
-
the only character entities supported are numeric ISOLatin-1 ones. Others
require accompanying files with EntitySets and some mapping to fonts and/or
glyphs.
-
does not store components of the prolog, doctypeDecl or similar information.
-
does not (at present) store external entity information
-
does not map attribute types onto attributes in the document
-
does not monitor uniqueness of id or name attributes
XLL
The following are currently not implemented
-
a generic attribute remapping process. This is more general than XLL and
IMO requires a special module
-
ROLE, CONTENT-ROLE, CONTENT-TITLE, INLINE, BEHAVIOR have little
formal guidance, so there is little generic to implement.
-
SHOW="EMBED" is difficult to implement in JUMBO's tree display
and within an event stream is application-dependent.
-
EXTENDED. There are no clear semantics here (I think some will
emerge). I am also not sure what the role of the attributes on EXTENDED
is - are they only for inheritability by child LOCATORs?
-
INLINE. The semantics of this are not defined.
-
STEPS attribute in GROUP. Until there is a model for
GROUP I shan't move on it
XPointers
The following are not implemented
-
connectors other than "#" (but this is really a server-side concern)
-
the ".." separator. I am not very clear where JUMBO may support spans as
this is probably application dependent and seems only to apply to event
streams. If not, then a generic mechanism needs to be carefully thought
about
-
HTML() and DITTO()
-
negative location steps
-
*CDATA and '.'
-
*IMPLIED and Name as attribute values. (I don't understand
the latter - perhaps the DTD is required?)
-
Offsets in STRING (although this is probably only a rendering
concern).
JDK and AWT limitations
JUMBO is deliberately restricted to JDK 1.02 so that it can run under browsers.
JDK 1.02 (especially the AWT) is known to have limitations, some of which
are highly browser-and platform-dependent. Many of the problems below should
disappear naturally when JUMBO is developed under JDK1.1 (the 9801 release
should be the last using 1.02).
Known problems:
-
scrolling is terrible on many platforms. Unfortunately HTML requires a
graphics surface since TextArea has not enough functionality and is only
usable for small amounts of hypertext.
-
updating is not always performed immediately. This means that scrollbars
are sometimes left hanging, surfaces not repainted, etc.
-
Free-standing windows (Frames) are often slow to instantiate.
-
Garbage-collection is conservative and occasionally gives out-of-memory
error. Restarting JUMBO is sometimes worthwhile
JUMBO Bugs
The following are design flaws which need to be resolved before the next
main release:
-
Attribute values of null and "" are not differentiated.
-
Nodes (elements) carry a great deal of member data and functions which
is allocated at instantiation time, but which has performance implications.
This should be replaced by lazy evaluation or a different hierarchy
-
SGMLAttlist is a poor name for the list of the actual attributes in a document
instance.
-
There are quite a number of classes in jumbo.simplegraph which
aren't quite right, and which overlap in functionality
-
The components of display are not optimal. Functions like display(), drawUnscaledObject()
may be replaced by getScalableComponent(), getUnscaledGraphicsArea() and
so forth. Not easy.
-
Some aspects of help are still messy (but being cleaned up)
The following are messy. I don't always have a complete diagnosis of the
problem.
-
The GIF reader (taken from Gamelan) seems to break on many GIFs. Offers
welcome!
-
Some of the URL handling routines are messy. Different platforms (especially
W95) seem to give problems with back/forward slashes, resolution of base
URLs, security exceptions, etc.
-
Some of the dialog boxes, file selectors, etc. do not always seem to work
as the Java spec implies
-
The multicomponent panel in JUMBO is not easily resizable. I have hacked
this at some length and so far failed. JDK1.1 or Swingset would be preferable
here.
Back to JUMBO index
Copyright Peter Murray-Rust, 1998