A number of discussions on the XLink/XPointer mailing list have led me to the conclusion that it's time to re-architect. I was going to have to do this eventually to improve scalability, but this presents an opportunity to add key functionality as well. For the most part, processing will be moving down the chain, from XLinkFilter to LinkSet and from LinkSet to Link. Link and LinkSet will become more co-dependent. Most of the functionality involved regards support for directionality. As XLinkFilter is all about resolving links to traversable (or non-traversable) paths between resources, providing more options for that resolution (and more hooks for applications to customize it) seems wise.
The LocationFilter class is a recent addition. It uses a Stack to provide the XLinkFilter class with information regarding the location of the current element in the document, and can produce (simple) XPointers for use in identifying inline link origin points. The LocationFilter is optional; turning it on requires code like the following (from XLinkUser):
The XLinkFilter may be used with HTML files, provided that they are well-formed. (All start tags must have matching end tags, empty tags must be indicated with /> (like <BR />), etc.) Your program must call setHTMLProcessing(true) to turn this on. See the XLinkUser file for an example.
JXML Inc. will be using XLinkFilter in the next iteration of Coins.
The XLink Filter is currently designed using Java 1.1, but may move to Java 1.2 if the benefits of the new collections seem worthwhile. A Java 1.1 version (for applets?) will hopefully remain available.