[
Lists Home |
Date Index |
Thread Index
]
Title: RE: [xml-dev] funny parser
In that scenario with particulars, (the telly schedule with one
source of update AND one occurrence context), it is true the risk
is minimal but doesn't that also mean 'one observer' and there is
still some risk for actors.
<topicalDrift>
I'm revisiting topic maps, so consider this a hobby horse reply.
Roger C., you might enjoy this: the structure for an update/substitution
isn't as important as the multiple contexts/occurrence (how the information
is used).
If feedback from the viewer can change the schedule, updates can get
but as long as this is one looped connection, nothing happens as long
as the viewer maintains one schedule and updates it before consulting
(sequence matters).
If multiple contributors to a single source (the
classic chaos maker) make uncoordinated contibutions, things
get very messy.
Consider a schedule for a cable system where multiple program directors are changing
their schedules and the cable provider is merging them, sending
them to the user, and the user is updating their own schedule(s)
(even without selection feedback to the source).
The update rate to the home subscriber becomes
a Schroedinger's Cat problem (how often
does the subscriber check when constructing/updating his own
local schedules). The presence of multiple occurrence types
means that for any substitution update there is a risk. The
new schedules are 'predictions' whose reliability changes
by observable context. The fact of pending change vs observed
time and act introduces risk.
Fun reference: Nikita Ogievetsky noted (http://www.cogx.com/kt2002/)
that there are quantum information issues in topic maps, so Nikita
proposed the quantum topic type.
I also noted this in Hytime papers some years ago though
I doubt any URI-documented references still exist. The problem
of C2 scheduling is an old one. We used the Space Shuttle ground
launch sequencer as an example. Midi sequencers exhibit time dilation.
There is considerable overlap between the SW work and
Quantum Information Theory (QIT). Orchestration helps
but cannot mitigate all of the risks. This is a general
problem of all real-time command and control systems as
has been noted in earlier papers (see early CASE systems, problems
of fly-by-wire in the Airbus, etc.).
</topicalDrift>
len
From: Robin Berjon [mailto:robin.berjon@expway.fr]
Bullard, Claude L (Len) wrote:
> Essentially the same "mess" as code patches. Same
> administrative overhead, same risks, same problems for
> multiple instances of the code (say customers).
Not quite and by a margin, there's only one source producing updates so
you remove all the issues to do with conflicts and merging. It's not
rocket science really, if you have a telly or a set top box that
provides program guide info (even if just "what's on now and next")
there's a very good chance that that's how it works. And it does work,
on half the brain of a 20th century mobile phone.
> Won't this resurrect the 'version' permathread?
Here's to hoping that it doesn't :)
| 