Re: [email@example.com: BOS confusion (analysis; suggestion to resolve Newcomb/Bryan conflict)]
At 04:19 PM 01/03/97 -0800, Derek Denny-Brown wrote:
>I think we could do quite well with a very simple notation for these
>extensions which includes simple query and tree location abilities. The
>extension is parsed similar to the path portion of the URL in that it is a
>"/" separated list of specializers/filters. If the specializer is a number,
>pick that subelement. If not it must conform to a <name>=<value> form where
><name> is an attribute name and <value> is an attribute value you are trying
>to match to. (this explanation is rushed bec. I want to beat traffic
That's what a TEI extended pointer is. The syntax is very compact, was
developed by a diverse international body, and has been implemented in both
DynaText and Panorama, so it's proven and already in use.
TEI extended pointers also do a lot more than the simple sketch above, like
allowing you to choose elements in all tree-directions (ancestors, children,
siblings, predecessors, followers, etc) based on position numbers and
filters on GI and/or attributes. They can also address into multidimensional
graphics and other media, do what HyTime calls spanlocs, and more.
If you haven't yet looked at the TEI guidelines section on extended
pointers, *please* look at http://dynaweb.ebt.com:8080/usrbooks/teip3/26759
(this link takes you directly to the section, with access available to the
rest of the guidlines). The spec is half the length of XML, it won't take
long. Since you can encapsulate a TEI pointer as a locating notation in
HyTime, we can have a rather nice cake and eat it too.