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

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

Comments inline...

On Tue, 2003-09-09 at 16:03, Art Botterell wrote:
> * Type names: the current CAP schema includes a number of "anonymous" 
> types... this breaks some implementation tools.  For the time being 
> they're using a convention that the type name equals the 
> corresponding element name; the SC agreed that this was appropriate. 
> Eliot Christian suggested that the TC may need to create a shared 
> collection of these types.  Rex Brooks agreed that it would be 
> beneficial to have these in an importable schema.  Gary Ham will 
> bring forward a proposal to include type names in the schema when we 
> revise it.  Consensus was that this wouldn't impact implementations 
> or the form of CAP message instances.

Hmmm, please correct me if I am wrong, but I do not think this is a DMIS
issue. Looks to me like an invalid schema issue. My understanding from
the XML Schema Part 2: Datatype (section 4.1.2), is that "name" is a
required attribute when defining a type
(http://www.w3.org/TR/xmlschema-2/#element-simpleType). Notice it is in
bold (http://www.w3.org/TR/xmlschema-1/#intro-terminology - read down to
where it says "In the XML representation, bold-face attribute
names..."). This would certainly explain why their parser is requiring
it.

> * SOAP encoding:  The initial DMIS implementation treats CAP 
> transmission as an RPC call and thus SOAP-encodes the message body. 
> As a result, the contents of the SOAP body are not, themselves, valid 
> against the standard schema.  Eliot reported that Microsoft is 
> avoiding such encodings due to interoperability problems between 
> various SOAP implementations.  Carl Reed said OGC tries to avoid 
> intrusions of higher-level protocols into message content.  Rex 
> Brooks noted that WSRP is explicitly SOAP-based.  Art expressed 
> concern that any deployment of an interface that features a 
> non-validateable representation of the CAP message could have the 
> practical effect of "forking" the standard, leading to 
> transport-dependence and non-interoperability.  

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. 

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. Of
course trying to address it could cause forks as well. Either way, there
is no clear and absolute answer. This issue to continue to be discussed
within the IF SC as we talked about last week
(http://www.oasis-open.org/archives/emergency/200309/msg00008.html).

> Gary Ham reported 
> that DMIS will switch from the RPC-style interface to a 
> message-oriented form where the SOAP body contents comply with the 
> committee-standard schema.  He said this interface should be 
> available by Friday.  The SC endorsed that choice, while 
> acknowledging that this makes implementation somewhat more demanding. 
> Art expressed hope that DMIS would then withdraw the non-compliant 
> (RPC) interface in order to support a standards-based approach.

I am not sure I would call this "non-compliant", but rather the
"compliance" ends a certain point in their app - just like any app. 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.

-- 
R. Allen Wyke
Chair, Emergency Management TC
emtc@nc.rr.com
http://www.oasis-open.org/committees/emergency