APIs

[Peter Murray-Rust]

Now that D-Day has passed off so successfully it's important that we get back to
APIs.  It's very exciting to hear of manufacturers who are committed to XML and
I hope this list can be a valuable place for them to trade ideas and information
where it's appropriate.  Lots of people will now be thinking about how to build
an XML system :-)  [Some of this is commercially sensitive, and xml-dev 
welcomes any members who are read-only :-).].

XML ideally lends itself to componentisation and I hope definition of some 
common components can arise soon.   For example, there are terms like
'XML processor', 'application', 'link processor', 'parser', 'editor', 'browser'
being mentioned.  

The present parsers (Lark and NXP) seem excellent examples of clear-cut 
components.  I interface with them either through Esis_Stream (NXP) or
Element (Lark).  I think we are the stage (following some very helpful 
earlier contributions) where we could work towards an API at this level - we
really need a volunteer to get a small virtual team off the ground, with some
milestones.  [I had to decline the offer to organise this as I have to get 
the Virtual School developed, and I've also got to develop CML.  I'd be happy 
to take part].  I'd stress that this needs to be simple - in the spirit of 
XML - remembering that a significant number of developers may have relatively
little prior experience of SGML.  [I'm really waiting for this to happen
so that I can rejig JUMBO internally - should I subclass its Nodes from
Elements, or should I build a new tree, for example?]

I would like comments on XML-LINK and a 'link processor'.  It seems logical
that parsers have some role in validating XML-LINK input (there are
some syntactic constraints that cannot be easily expressed in a conventional
DTD, such as that EXTENDED elements can only contain LOCATORs (and #PCDATA).
Of course this can be done explicitly, perhaps through parameter entities.).
I have ended up putting most of the XML-LINK processing under my Attlist
class, so that a Node (Element) can be asked isLink() when being traversed
(this is necessary for ACTUATE=AUTO functionality).  We must remember that
tree traversal can occur in different contexts and SHOW may not always be 
graphical.

I have hacked some of EMBED yesterday and would like comments.  In JUMBO
there are two sorts of autonomous 'windows' (Java Frames) - one for the
Tree (= TOC) and the others for individual nodes.  EMBED/REPLACE/NEW are 
relatively straightforward for TOCs but less clear for the others (e.g.
how does one EMBED a BIBliography in a MOLecule? Can the 'host' refuse :-)
In fact I tend to come down to EMBEDing only in hypertextlike objects which
work on an Event stream (e.g. HTML).  In that context I use:
	<IMG SRC=<target> XML-LINK="SIMPLE" SHOW="EMBED" ACTUATE="AUTO">
and require the target (say FOO) to have a FOO.display(Graphics) method.
The hypertext provides a screen area into which FOO draws its normal output.
This works quite nicely (though I'm not an expert here).  Therefore there
is an implicit convention that an Embeddable has a display(g) routine (this
could be formalised in an API Interface).  With inline strings I use
	<A HREF=<target> XML-LINK="SIMPLE" SHOW="EMBED" ACTUATE=AUTO/USER>
With AUTO the *text* of FOO is inserted automatically , and FOO must have
a toString() method.  With USER, it is inserted when the hypertext is clicked.
(All these also allow clicking to display the whole target as a free-standing
object, e.g. clicking on the first  IMG will display() FOO as a free-standing
Frame.).  
	An important thing is that this is all largely *application-independent*
The targets have no knowledge they will be embedded (and they often don't know
even when they *have* been!).  The Embedders are a select company, TOC, 
HyperFlow (my **crude** HTML renderer - anyone got a better one?), and one or
two application classes.  

	I am very keen that this interfaces with other browsers (I'm a chemist
not a software person :-) and would like to be able to (say) get a browser
from elsewhere and know that it supports XML-LANG, XML-LINK at an 
application-independent level (e.g. stuff like that above), and good 
interactivity with Java.  One thing I'd really like to able to do is get an
application class to create some hypertext, send it to the browser for display
but know that the browser will route back any XML-LINK events.  If that is
achievable, WOW!

	HTMS

	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)