[
Lists Home |
Date Index |
Thread Index
]
You are right that a Draconian parse constraint can't
always be obeyed, but any sensible programmer knows
that. On the other hand, it can't be ignored either.
When XML was being designed, I don't think Tim Bray
had C3I in mind for the web although weirdly enough,
that is what the Internet was designed for.
As to the public safety issue:
A phone call is a phone call is a phone call. At
the edge of any ecosystem, the boundary should be
highly permeable. The more rigid structures are
internal. Note the definition of ecotone.
http://www.uwsp.edu/geo/projects/virtdept/ipvft/stop3.html
It is a transition boundary.
In a real time system, the question is, is the message
actionable? Given an overlapping boundary, the ecotone,
what actions are taken given an ambiguous message?
In a Dispatch center, they use multiple sources of
information to increase the precision of the response.
1. The person on the phone is highly agitated. The
call desk is trained to calm them while continuing to
get more precise information from them.
2. The call is traced to its location resulting in a
geocoordinate used to provide to the responder the
fastest route to the location of the incident. That
is why you pay a tax for tower location or GPS location
processing on your cell phone. In some cases, as soon
as you dial 911, your cell phone begins to transmit
the GPS location and locks up your ability to use it
to place a call. This is a pain in the ass for a
fender bender so beware of who you call first if there
are no injuries. Also, information has been recorded
about previous calls for service at that location to
enable alerts to the responders.
3. The information is reused given a proper public
safety system and here is where your question is more
germane. It may be used, for example, to provide information
to your utilities service provider so that they can also
dispatch repair crews. This very handy in a major incident
such as a hurricane. They may also communicate with other
customer facing systems such as providers of gear, etc.
The value of intelligence is in the way that you use it.
Note that in public safety we can't set a goal of eviscerating
our competitors. Given multiple jurisdictions, we have to
interoperate with their software and hardware or we will
eviscerate our customer's customer. That is you and me,
Michael, so consider it a fundamental value of our business.
In cases like this, the communication contract is vital
and schema validation in real time can be very useful. We
wouldn't stop the message: we'd use the schema as a fast
cheap way to test it because it does have errors or exceptions,
we need to know that as rapidly as possible. This is
also true of intelligence exchanges where the intelligence
is being fused for high level thin management to make not-quite-real
time assessments for command and control such as asset disposition,
mission planning, and so on.
len
From: Michael Champion [mailto:mc@xegesis.org]
Just curious ... hypothetically what could/should a public safety
agency do with a CFS event that didn't conform to some future
structural contract / schema that it was supposed to conform to?
Obviously "nyah, nyah, invalid message, let the poor sucker bleed" is
not the right answer. On the other hand, letting the bug in somebody's
procedures or code go un-reported is not a great idea either. I guess
this echoes the eternal RSS/Atom debate over draconian error
processing, and I suspect that all the myriad ways that RSS gets
ill-formed in practice will be revisited as XML becomes pervasive in
other situations.
I'm thinking these days that schema validation has a big role to play
in test-driven development but is of highly doubtful value in
operational situations, or at least ones in which people can die or
fortunes be lost if a message that is otherwise meaningful is rejected
for "mechanical" XML reasons.
Also, to address one of the issues that came up in this thread, I think
that declarative vs procedural definition of the validation rules is a
question that is orthogonal to this one. In general I agree with
Roger's summary, but we can imagine "structural" constraints that
could only be validated procedurally ['the value in field X must be a
prime number' is the classic, if contrived example]. We can also
imagine "semantic" constraints that could be validated with a
declarative rule-based system, and anyway query languages such as SQL
and XQuery seem to live in the fuzzy middle ground between declarative
and procedural.
|
