Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: XLink transformations
 From: KenNorth [mailto:KenNorth@e...] Len, > Note: often such operations require querying the actual > system containers for existence information, to reliably create > new containers, etc. > Because each locator type has variable sensitivity to transform operations, it must be accounted for in the design and each operation type may be more or less reliable given the locator type. You don't say it explicitly, but you are stating the case for the need for integrity constraints -- and even better -- container-enforced constraints. >>Yes, I think so. In effect, and you know the drill, we often have to call the system to get the contexts needed to create new containers. So, operational rules if not shared will result in discontinuities and that limits interoperability. Effectively, the rules of the implementation framework get involved. > defined in the vancouver presentation on views over documents. What presentation? Do you know a URL? >>Sadly there is none. This all predates the World Wide Web. We were doing CALS then. The first Vancouver presentation dealt with providing a formula for view dimensions. The next year I presented the work on information ecosystems which was, IMO, a metaphorical way to model large loosely coupled systems. I had done no work with relational systems to that point, so this stuff was windy at best. I was doing a bit of work for David Taylor Model Basin (Carderock) on advanced IETMs. Because of all of the previous work I'd done at GE on Beyond The Book Metaphor after we completed the GE TM Authoring System for CASS, I was still looking hard at the issues on non-linearity and what I called view dimensions. Paul Grosso and Paula Angerstein told me once it all read like magic and they were probably right. I am a musician/writer and a self-taught computer geek, so not trained for the tasks I was attempting. On the other hand, sometimes not knowing details and being able to do breadth vs depth research is a good road to prophecy if not standards. I wish I had the formula because it was cool. Neill Kipp may have it somewhere. :-) The notion was the need to use concepts such as rules, schedules, and contexts for loosely coupled systems that require synchronization. Really, if one uses event scheduling, synchronization can be loose and that is why I use the Ringo story to illustrate the discoverability of events by which one can reliably, stay in beat. Event driving is better than scheduling if the views are constrained and real time systems design takes this up as part of the limiting chaos problem. IETMs are pre-condition/post-condition driven systems of instructions. I think in the early Hytime days, we over-obsessed a bit over synchronization and overemphasized the locking where the case is that for loosely coupled systems, event recognition is more important. Nesting the business processes was well understood but joining them for concurrent execution wasn't although that problem isn't that hard. The issue I was taking up at that time was hidden coupling, the Huygens Clock problem. The dilemma is to ensure efficient just in time scheduling which is safe to execute. An example is repair on systems such as wings where one guy can be working on one side of the aircraft while another is on the other side. If one tests a flight surface, he might kill the other fellow. Other applications were schedules for things that require inspections to be safe; eg, a missile launch. Then there is resource scheduling and reallocation in which part of the precondition for executing the process is a tool or part. Not very dramatic stuff but interesting. Again, it requires one to analyse the ranges of coupling strength and make determinations based on these about scaling time quanta in a schedule. I have copies of the GE work and the correspondence between myself and Dr Newcomb, as well as some stuff on frame-based hypertext a la IADS, but none of the US Navy work where this was published. The non-linear stuff freaked out the program manager and she demanded it be removed after the drafts were submitted. So I doubt the navy has it either. After the first Vancouver conference, the British Library asked for copies of Beyond The Book Metaphor but someone in DC refused it and said it was "non-exportable". The silliness of that is that most of the concepts had been published in Enterprise Engineering for Concurrent Integrated Product Development and Support Environments (GE Aircraft Engines) at a CALS Washington Conference in 90-91. I've seen it referenced in some European presentations but mostly, I think all of the early work was just too early for most people to pay attention to, and it was hard to get if one wasn't in the DoD circles. Also, there was a presentation at a GCA TechDoc Winter conference about the same period. The fellow to contact that owned the documents at GE Aircraft Engines is Bruce Schoolfield (Cinncinatti). "Left wing lunatic fringe" stuff but fun. Again, as I told someone else, revisiting all of this is like listening to my old recordings from my youth. Naive, precocious, pure and thankfully, over. It didn't come to much but reading the MS .net stuff is fun because similar concepts are emerging. I take no credit for that but I think given similar problems and shared approaches (eg, markup) very similar conclusions are reached. Ack... called away to a meeting. Rats. len 
|
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
|
|||||||||
