XML-LINK implementation

[Peter Murray-Rust]

I have nearly finished a prototype implementation of XML-LINK 970406 within 
JUMBO and hope to make this available in a week or so.  Here are some 
interim comments.  Of course it is all 'unusually volatile' :-).

[I have not yet converted TEI to use commas, and negative numbers are not 
supported in PRECEDING, but these should be done shortly].

In document order:

1.4 'multi-directional link'  There is no explicit syntactic support for this
and at present this would have to be done be creating the appropriate number
of SIMPLE or LOCATOR elements.  I am assuming that this is the ERB's intention.

2.1 **Default Attribute Values**.  This appears to be a parser requirement
and I'd be grateful if Norbert and Tim (and any other parser writers) could 
express their views.  At present all my test examples are based on explicit
attributes in the document.  Parser development would be highly desirable.

**General point**  XML-LINK applies to WF as well as valid documents.  There are
many things that can produce apparently meaningless documents (e.g. linking
from one WF|valid document to another WF|valid which might reasonably throw
errors but the spec has not (yet) commented on these - I hope it will later.

3.1 
ROLE, BEHAVIOR, TITLE.  I have treated these all identically and trivially
(i.e. they are simple String variables available for later use).  They
may/maynot be present and they will be inherited if present in EXTENDED
but not in the child LOCATORs.  As a consequence, sibling locators may all
end up with identical TITLEs - this may be an authoring concern.

3.2 ATTLISTs

I struggled with these a bit, before coming to the conclusion that a 
link processor might have to deal with these in detail independently of the 
parser.

I assume that these will be hardcoded into LINK-aware parsers (or at least 
into tables that parsers read.)  A parser might then identify all the elements
with attribute XML-LINK and apply the 5 tables to the documents.  Remember that
the document may not have a DTD.  **Can the parser assume that if one element
FOO in a WF doc uses XML-LINK then all FOO do?**  

However we must also assume that some parsers are NOT LINK-aware and therefore 
willhave to validate the tables and provide the defaults and inheritance.  
*** any XML-LINK processor must therefore cater for this***.  
I thought about re-using
Norbert's code but in the end (also being very tired) hacked something 
internally.  **However this is an important area for an API - we need tools
off the shelf that deal with these tables - it's just conceivable they may
be subject to future revision :-)***

I haven't run into any obvious problems implementing defaults and inheritance.
*** formally it is allowed to have a LOCATOR element not contained within
an EXTENDED.  This seems meaningful - is it what the ERB intends?**

4.1

***general point***  It seems quite possible and desirable to have a LINK
processor which is independent of the application.  Of course it depends what 
is an application, and JUMBO may be called an application.  However I think
it could be broken into components.

Essentially JUMBO holds the parsed document as a tree of nodes (==elements).
At present every node has a  button linked to display().  This corresponds
to NEW/USER.  When the button (an element-specific icon) is clicked a separate
window is launched with that node displayed.  [The default Node.display() is
simply to print the node structure on System.out.]  display() is overriden
for DrawableNodes (which extend Node) and where a general purpose window is 
provided.

If the user wants to draw to the same screen as the referrer (EMBED) there is a 
module display(Graphics g).  The control of the Graphics area is under the
referring window, although the target may be able to say something
about its size, scalability, isometricity, etc.  In this way 
EMBED/USER is possible at present - when clicked the target is redrawn onto
an appropriate place on the referring window. (Since I didn't know I was going
to be writing a browser when I started there are some things which need 
rewriting.  Also JDK1.02 is horrible for multiple window components and I shall
not change to 1.1 until it's in the browsers.)

REPLACE/USER is also dealt with.  This means that the current tree (in the 
TOC) is overwritten with the new one - the only question is one of window
management and some Java tweaks - I think it needs a shallowCopy of the tree).

All the */AUTO imply that the first time the tree is traversed these operations
have to be done.  When initially creating the tree I now note whether there
are any XML-LINKs in it, so I don't have to wait for a paint().  For example
the first REPLACE/AUTO in the document simply involves creating the referred
resource (recursively if required - I hope it's not cyclic!!).  NEW/AUTO 
requires one or more new windows to be created.  EMBED/AUTO sets an embed
flag in just the same way as if the EMBED/USER had been clicked.

All of these can be done ***independently of any application*** so long as we 
agree on an API.  At present an Element/Node seems to need (minimally):
	void display(Graphics g)
	boolean isEmbedded
	void createNewWindow()
beyond that I suspect that everything else is likely to be part of the 
application.

I have commented on  Section 5 here and to the WG, and won't repeat that here.
There are no real implementation issues but I am arguing for some clarification
and feature creep.

JUMBO does nothing with GROUP/DOCUMENT (other than throw an error for absent
HREF).  This would seem to be entirely application-dependent.

Comments welcome.  I will notify the WG of this posting.

	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)