[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas
My 2 cents on a “Profile” definition…this one is for HAVE- but applies to all Profiles…
The following are the attributes of a HAVE Haiti Profile message that are required:
· A HAVE Haiti Profile message must NOT become a new or additional “standard” (e.g. another Hospital Availability standard or another HAVE 1.0 “version”).
· A HAVE Haiti Profile message must NOT be a Proprietary Format.
· A HAVE Haiti Profile message must comply with the HAVE 1.0 standard.
o A HAVE Haiti Profile message must validate against the HAVE 1.0 standard schema.
o A HAVE Haiti Profile message must validate within the HAVE 1.0 standard namespace with no changes to root elements.
o A HAVE Haiti Profile message must use all required elements (i.e. no deletion of required elements are allowed).
o A HAVE Haiti Profile message must not change attributes for required fields.
The following are recommendations for clarity:
HAVE Haiti Profile message may further constrain the HAVE 1.0
HAVE Haiti Profile message may add to required element
· A HAVE Haiti Profile message may limit size of required elements.
· A HAVE Haiti Profile message may exclude optional elements.
· A HAVE Haiti Profile message may use optional elements in a specific way – as defined for the profile.
The aim of education should be to teach us rather how to think, than what to think - rather to improve our minds, so as to enable us to think for ourselves, than to load the memory with thoughts of other men. ~Bill Beattie
That is not what I said!
I said that if it meets that CAP schema IT IS made available for retrieval, but it will only be pushed to gateways if it meets THEIR respective profiles and permission requirements.
So, one cap Message could be sent to 0 to many external gateways depending on its content and the permission of its authors.
But even a zero gateway message that meets basic CAP schema would be available to authorized pull entities.
Additionally a separate request capability will let authors learn the gateway fate of otherwise acceptable messages. This is not done yet, but is the general plan.
On Mar 9, 2010, at 4:37 PM, Paulsen,Norm [Ontario] wrote:
Actually I shouldn't have used the word forwarding as it implies pushing and I too prefer polling/pulling.
So if a CAP message meets the CAP schema but not a known profile it is not processed further and not made available. Good to know.
All I ask is that any reporting of failure distinguishes CAP schema failure from profile failures.
Other than that, it was just a soapbox moment that I took.
From: Gary Ham [mailto:firstname.lastname@example.org]
I think you misunderstand,
IPAWS-OPEN will take any valid CAP message as long as the sender is authorized, and make it retrievable by any who are authorized to retrieve. The retriever can then determine if the message is useful on their net or not. But pushes are another matter. Before DM-OPEN pushes out a message it has received for re-transport (e.g., NWEMs to the NWS, and perhaps Canadian profile message???) it will test against whatever profile the receiver requires, and will not process further if it does not meet the profile. That is why pushes are a pain, and why we will have to negotiate each push arrangement separately and have a formal agreement with the system we push to. Pulls are a lot less of a problem for us because the pulling system can deal with the issues.
On Mar 9, 2010, at 4:14 PM, Paulsen,Norm [Ontario] wrote:
Not quite sure exactly what you mean by structure, but it sounds like it will not accept anything that doesn't have elements with values specific to these concerns. This contradicts the line that says takes any valid CAP message.
However, I have no problem with IPAWS-OPEN doing that at all. I also no problem with IPAWS-OPEN requiring my Canadian Structure before accepting my CAP and forwarding.
What I need to stress is that if indeed it is only open to these "structures" then it can't be truly said to be accepting any valid CAP message. It can though be said to be accepting of any CAP IPAWS message (if indeed those structures are defined in IPAWS).
From: Gary Ham [mailto:email@example.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.