RE: Designing XML to Support Information Evolution

In what order did you learn these lessons (no pun intended). It sounded like you learned that order hurts after you had already flattened the structure.  

 

I started with the highly hierarchical structure first.  Then I flattened it out by putting the Pickers after all the lots (and dropping the <tract> elements.  Lastly, I freed up things so that the order of the lots and Pickers was irrelevant.

 

<random_musings_after_long_conference_day> 

 

What conference, might I inquire?

 

I was also making guesses about "moving" a picker from one tract to another. I wondered if the picker was known a priori (i.e., looking for a job) or if the tract simply wanted any available picker. If the tract wanted a specific picker (the tract owner's son for instance) then in the real world someone (the application) would have to go and check each tract until they found him-- this again seems like the hierarchal model more adequately represents the real world-- while we can all recognize that simply looping through all of the pickers would be quicker.  

 

Actually, each Picker makes it decisions locally, by looking at neighboring lots.  There is no top-down code telling each Picker how to move.  It is a bottom-up approach to the Vineyard system.  This is for an "XML and Complex System's" tutorial that I am putting together. 

 

This brings me to my next question(s): were the "problems" speed oriented or only difficulty oriented? Other than number of lines, what specifically made it difficult? What did all of those lines contain?  

 

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

 

Finally, and as an aside, why didn't you choose to use RDF in the flat model.  

 

An interesting idea!  I shall think about this.  Thanks!  /Roger