xml-dev - RE: XLink transformations

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

From: KenNorth [mailto:KenNorth@email.msn.com]
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