On Wed, 15 Oct 1997, Paul Prescod wrote:
> As I understand it, CONCUR allows the same elements to be described
> according to two different tree structures. But each tree structure is
> still strictly a tree and strictly distinct. You must parse according to
> one tree ("concurrent instance") or the other, while Edmund wants to
> parse according to both at the same time.
 
In an interactive tool -- especially an editor, but I can think of other
examples -- you are likely to want to mantain concurrent data
structures.  Whether you do a one-pass or a 14-pass parse :-), the
result is that given
 
   <(staff)employee.name>
     <(people)first>Ichabod</(people)first>
     <(people)last>Arbuthnot</(people)last>
   </(staff)employee.name>
 
(using a non-overlapping example),
 
if a user of an editor changes Ichabod to Simon (say), the editor must
manage keeping both trees updated, or have both trees share the text
nodes containing cdata.
 
Either way can be fairly complex, although I can certainly see that
it's possible.
 
> In fact, CONCUR strikes me as an early variant of architectural forms.
 
Yes, in some ways, except with less control...
 
Lee
 
--
Liam Quin --  the barefoot typographer -- Toronto
lq-text: freely available Unix text retrieval
 
email address: l i a m q u i n, at host: i n t e r l o g  dot  c o m