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


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas

On re-reading this - I really like what you have spelled out - all those constructs could be expressed in a CAM template profile - and that provided to implementers to Canadian CAP to validate against - in addition to the base OASIS schema check.
I also like Gary's mantra - Data driven, as simple as possible, as complex as necessary.
I'd add to that - context driven and adaptive content handling - rather than brittle and static.  This ensures a system can receive and process as wide a range of inputs without failing and with making best efforts to process them effectively.  Safely ignoring what it does not need - but ensuring that a minimum core content is handled always.

Thanks, DW
-------- Original Message --------
Subject: Re: [emergency] HAVE Conformance vs. Documentation vs.
Released Schemas
From: Gary Ham <gham@grandpaham.com>
Date: Tue, March 09, 2010 3:52 pm
To: "Paulsen,Norm [Ontario]" <Norm.Paulsen@ec.gc.ca>
Cc: "McGarry, Donald P." <dmcgarry@mitre.org>, "David RR Webber (XML)"
<david@drrw.info>, <emergency@lists.oasis-open.org>,
"Dwarkanath,Sukumar - INTL" <Sukumar_Dwarkanath@sra.com>

I cannot speak details for IPAWS specifically, because not all aspects have been built or even designed, but I can give some general direction. IPAWS-OPEN (yep 3.0 will be called IPAWS-OPEN) is planned to have a single CAP input interface that takes any valid CAP message.  Depending on content (does it have the appropriate CMAS structures, EAS structures, NWEM structures, etc), user permissions, and user direction, it will be made available to multiple other networks, gateways, interoperating systems, push capabilities, etc., as applicable.  Data driven, as simple as possible, as complex as necessary. That is the goal. 


On Mar 9, 2010, at 3:27 PM, Paulsen,Norm [Ontario] wrote:

I both agree and disagree with your following line..."The TC’s official answer to documentation issues and referenced schemas shouldn’t be to tell developers to go off and make their own profiles…I think we are just shooting ourselves in the foot."
I agree that developers should not go off an make their own profile. Developers of equipment and software should build to the standard. The TC should not be promoting profiles.
However, when a system is designed to solve a business need, there will be business and system issues to deal with. Some of these issues can be profiled as long as the resulting CAP message is still valid CAP as per the CAP standard. For example, if a system makes <info> or <language> required instead of optional then the resulting message is still valid CAP and any receiving equipment built to CAP will still work. On the other hand, if a system were to make a required element optional then a message without the element would not be valid CAP, and hence the schema it is based on is not a true CAP profile.
Receiving equipment should definitely be built to the CAP standard (the TC should encourage this strongly). On the other hand, the CAP message generation equipment should build valid CAP messages, even if it does accommodate a profile in doing so, but again, as long as it is valid CAP. The TC, while not necessarily promoting this, should not lobby against it either.
So what is a profile?....
The Canadian Profile starts right off by saying that any CAP-CP message must be valid CAP (its our rule 1). Therefore, we expect our messages to be fully interoperable with everyone else's technically. Our profile goes on to comment on a few other similar technical issues like <language>, but really the bulk of our profile addresses the business of Alerting for Canada...such as our event code lists. We just happen to call all of it (the technical and the business) our profile. Therefore, we would expect a transform between our CAP message and event list to the IPAWS CAP message and event list. This is easy to do in a gateway function if IPAWS wants to use our CAP. This is how we make the business side of the message interoperable.
Alternatively, CAP also allows for both profiles to be accommodated in a single message through the use of multiple entries of the same element; in other words I can place two <eventCode> elements in one message with one having the SAME code and the other having the Canadian Code. This is easy to do especially if value list URN's or URI's are used. Hence my generation software can accommodate both profiles in one message.
We also have separated our profile into three documents where two of them we wouldn't even dare to forward to OASIS or the TC for comment or approval as they simply address the business side of the system. The one document that we would send up for review just talks about the few technical concerns that we feel does not violate rule 1. And if they are found to do so, we will fix and change them, not rule 1.
We are of the opinion that a CAP validator should not validate a system (such as IPAWS or CAP-CP) but just validate CAP.  This is a technical validator. Additionally, the system that operates a profile should be responsible to have a system profile validator that validates the business system. My concern is in how much of a distinction FEMA/DHS have made in this regard.
Developers that develop to CAP will be the ones far better off.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]