Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Designing XML to Support Information Evolution
 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. Cheers, Tom P 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
