Lists Home |
Date Index |
- From: Peter Murray-Rust <email@example.com>
- To: firstname.lastname@example.org
- Date: Tue, 23 Dec 1997 16:02:04
At 14:25 23/12/97 +0100, email@example.com wrote:
>>My query interface uses XLL TEIpointers, something like:
>>Node node = tree.TEISearchFirstNode("DESCENDANT(1,MOL)");
>>Since XLL systems are required to provide TEIaddressing, it's trivial to
>>use it as a search query as well.
>I haven't really studied TEI pointers yet. From what I remeber they look
It's worth taking the time :-) They are very powerful. And of course they
>like the HyTime tree addressing mode which I understand as basically giving
>indices into a tree e.g. (1,2,3) meaning from the root element the second
>child and from this the third child.But it looks like you can specify some
I can't answer authoritatively for HyTime, but the present XLL addressing
scheme owed a *great* deal to the HyTime effort and (IMO) is an excellent
middle point between the total power but abstraction of HyTime and nothing
>This is surely a nice way to address things but if used in queries it seems
>to bind the query to an exact tree layout. That' why I prefer purely
No. It has to be a tree, but the exact layout does *not* need to be known.
>property based queries because then the locations of the elements can
>change but my client still gets the information it wants (if it is still in
>the tree somewhere). And change it will...
This is precisely why it is so powerful - it does not need to know the
exact structure. As an example, JUMBO uses a variety of tree-structured
components and ancillary files:
- DTDs (in tree form - gurus tell me this is a simple "grove")
- namespace information
- mime types
Let's assume that this is agglomerated into a single large tree, which
continues to grow as I add more bits on. And as my brain is mature and
therefore full, I can never remember where the bits are. BUT suppose I know
that I want to find all menu items which have the word "Print" in (I might
have written a print output routine, for example. *Without* referring back
to anything I can write:
NodeSet printNodes =
All I have to remember is that there are things called MENUITEMs which
occur *somewhere* within MENUs and I only want those with String content
(PCDATA) which somewhere contains the substring "Print". Then no matter how
much the tree is edited. merged, or whatever, *so long as the MENUITEMs
occur within the subtree of MENUs* the search will be valid. Wow!
If you are interested, JUMBO contains this functionality which is within
the letter and the spirit of the XLL spec. It can be extended by obvious
means, but I am reluctant to do anything that might compromise the
boundaries of the spec. [The area that is most problematic is
case-sensitivity, because I am sure that people will want it, but the spec
is adamant that - at present - all components of the string above are
case-sensitive. Extensions to regexps, etc. are also "obvious".].
>>>Solution: Turn some information tree into a blackboard.
>>I suspect that XLL XML-LINK="EXTENDED" can be used here. This can be used
>>to capture the non-hierarchical relations. How *generic* it can be, is
>>something which I think we have not resolved.
>I had something more profane in mind: if the implementation of a DOM node
>also implements an observer interface then clients can register for changes
This is the software implementation I assume - (e.g. the Java Observable
class). You make "connections" between the observer and the observable. In
XLL (AIUI) this can be done with EXTENDED links - you can link one set of
"resources" to another set. That could then, of course, be implemented by
the Observer mechanism. So a *document* can mandate that when document A
changes, addresses B should be notified. [But I'm not an expert].
>in elements or element content. This is a solution if you need to separate
>publishers from subscribers without going to an object bus technology right
>away. The document tree provides a structured medium for decoupled
>communication between objects.
Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)