[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML as a programming tool

• From: Peter Murray-Rust <peter@u...>
• To: xml-dev@i...
• Date: Tue, 23 Dec 1997 16:02:04

At 14:25 23/12/97 +0100, walter.kriha@s... 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
are tested.

>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
>properties too.

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
at all. 
>
>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
	- menus

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 =
jumboTree.TEISearch("ROOT()DESCENDANT(ALL,MENU)DESCENDANT(ALL,MENUITEM)STRIN
G(1,"Print",0)

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".].

	P.

>
>
>
>>>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.

	P.

Peter Murray-Rust, Director Virtual School of Molecular Sciences, domestic
net connection
VSMS http://www.nottingham.ac.uk/vsms, Virtual Hyperglossary
http://www.venus.co.uk/vhg

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)

• References:
  • Re: XML as a programming tool
    • From: walter.kriha@s...

• Prev by Date: Re: XML as a programming tool
• Next by Date: Re: Christmas Interruptions (and SPAM)
• Previous by thread: Re: XML as a programming tool
• Next by thread: Re: GEDCOM model in XML
• Index(es):
  • Date
  • Thread