Re: [emergency-msg] Minutes from 9-9-03 Notifications SC call

["R. Allen Wyke" <emtc@nc.rr.com>]

On Sat, 2003-09-20 at 15:18, Art Botterell wrote:
> At 12:35 PM -0400 9/20/03, R. Allen Wyke wrote:
> >Hmmm, please correct me if I am wrong, but I do not think this is a DMIS
> >issue.
> 
> Allen, we worked this over at some length in the SC meetings of the 
> past two weeks.  The problem was with DMIS applying the optional SOAP 
> encoding rules unnecessarily in a messaging-style application.  That 
> created a divergent format on the wire.  DMIS took our feedback on 
> board and implemented a messaging-style SOAP interface.

Actually, this was not in reference to the encoding issue - it was in
reference to the fact the <simpleType> declarations in the schema are
missing what appears to me as a required name attribute. Sorry for the
confusion.

> >This is exactly why transport needs to be outside of the CAP standard
> >itself. So any "fork" does not become that, but rather because "here is
> >how you apply this standard to transport situation A, which might be
> >slightly different than B, etc." How many types of transports we want to
> >consider, think about, decide to avoid all together, etc. is something
> >we should discuss.
> 
> I don't think we want to say that every transport network can use a 
> different schema.  Devices should be able to implement multiple 
> transports without having to implement multiple document schemas as 
> well.  Especially when there's no necessity to do so.

I agree, but that is not what I was trying to say. I was saying the CAP
format stays constant - everyone uses it. Someone using it in a Web
Service implementation (Web Service being the transport) might do it one
way, while someone using plain ole HTTP POST might do it a different
way. 

>From a standards perspective, I was saying that we should try to address
this outside of CAP since it is not CAP specific. For instance, when
someone comes to us and says, how do I create a CAP compliant app that
sends data via HTTP? We all technically know different ways, but there
is not "official" or "recommended" way. Failure to supplying this could
create undesired forks.

> The real question is "what constitutes compliance with the standard?" 
> The current document specifies, as normative, an XML schema that 
> defines a message representation.  If the schema isn't the criterion 
> then there's no limit to how many different, incompatible "CAP" 
> formats might be deployed.

The schema, from CAPs perspective, is the criteria. Is anyone thinking
otherwise?

> >If we take the stance, which needs to be discussed amongst the whole TC,
> >that transport is something we chose not to touch with a 10 foot pole,
> >then that is fine - but we will need to be prepared for forking.
> 
> Our approach all along has been that the message format should be 
> independent of, and standard across, transport options... precisely 
> so that different transport choices didn't induce standards forks. 
> Whether we address transport as an Infrastructure issue is, and 
> should be, an entirely separate question.  Our immediate concern was 
> that we not come right out of the box with two different flavors of 
> CAP documents being exchanged among users.

My point exactly. I could not agree more.

> >  Take the now famous "broadcast" scenario. One version of that is most likely
> >delivered in voice, which means the last mile was not CAP - it was CAP
> >transformed into something someone spoke or there was a text-to-speech
> >transformation.
> 
> That's the easy case, of course.  The version we've been wrestling 
> with is the one where the broadcast link isn't the last mile, but may 
> be used to pass standard-compliant messages to third-party consumers 
> (devices and/or networks) at the far end.

The question one has to answer before finding an answer here is, "are
the sending and receiving applications in this, or any, scenario the
responsibility of different parties?" My guess is yes and no.

Yes: in this case, each application, last mile or not, must provide a
standardized CAP interface. Currently that means they support the
format, which doesn't buy you a whole lot. "How" they support it (aka
transport) is the tricky issue and is what the IF SC is helping us look
into.

No: if point A and point B are within the same app/party, then frankly
they *should* do whatever is best for them and their business. This
means they may transform CAP into some proprietary format to help reduce
bandwidth load or perhaps to support their existing infrastructure. Or,
it may mean they are building from the ground up and want to treat as to
separate CAP-compliant apps - one sending and one receiving. How they do
it is really up to them, as long as their external interfaces are
CAP-compliant - well, assuming they want that of course.

Allen

> - Art
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/emergency-msg/members/leave_workgroup.php.
-- 
R. Allen Wyke
Chair, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency