OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Designing XML to Support Information Evolution

[ Lists Home | Date Index | Thread Index ]

Roger L. Costello wrote:

> One of my requirements  is to be able to process each lot (and the Pickers
> on the lot) concurrently. The hierarchical approach (as well as the
> approach that mandated a specific order) forced the lots to be processed
> sequentially.  

Well, not necessarily.  You were using xslt, right?  The processing 
order is not specified, only the final order in the result tree.  XT, 
for example (it may be the only one), does parallelize its work and 
interleaves it at the end, as I understand it.

> Let me try to give an intuition on why this is so.  Consider
> three adjacent lots on the Vineyard, with Pickers on the two outer lots, and
> no Picker on the inner lot.  Each Picker concurrently makes its decision
> where to move, based upon local information (i.e., how many ripe grapes are
> in neighboring lots).  Suppose that both Pickers elect to move to the inner
> lot (many ripe grapes there).  Picker 1 removes itself from the lot that it
> currently resides on and positions itself onto the inner lot.  The two lots
> are written to the XSLT result tree.  However, Picker 2 is doing the same
> thing.  Thus, in the result tree we now have two different versions of the
> inner lot.  

Do you meant that there would be an attempt to write the same attribute 
twice with different values?  But if you had the parallel processing you 
say you seek, the same thing would have to happen - both pickers would 
assign themselves to the same lot since there would have been no 
sequencing to prevent it.  And the result would have been the same.

To capture the result, you could not use an attribute, you would need an 
element structure.  But if the problem was not a multivalue attribute 
then I don't see what the problem was at all.

> The only way that I could see how to do it was to first process
> Picker 1, then process Picker 2 using the state that resulted after
> processing Picker 1, i.e., process the lots/Pickers sequentially.  I hope
> that I made some sense in this description.

Wait a bit, something does not add up here.  Given what I said just 
above, you should have _wanted_ to have two pickers on the same lot. 
Now you say you had to prevent it.

You are really thinking about a society of agents here, are you not? 
The agents have to communicate and negotiate in a case like this, so who 
cares if you had a collision on one step?  It would need to be resolved 
either way.

In xslt, that would be done with a separate template to resolve the 
collision, to be invoked instead of the normal template handling that match.


Tom P


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS