OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] Are people really using Identity constraints specif ied in

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


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.


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.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS