[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: ·
A
HAVE Haiti Profile message may further constrain the HAVE 1.0
standard.* ·
A
HAVE Haiti Profile message may add to required element
definitions.* ·
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. Thanks, Lee 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 From: Gary Ham
[mailto:gham@grandpaham.com] 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. Gary 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. Thanks From: Gary Ham [mailto:gham@grandpaham.com] 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. Gary On Mar 9, 2010, at 4:14 PM, Paulsen,Norm [Ontario] wrote:
Thanks 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). Thanks Norm From: Gary Ham [mailto:gham@grandpaham.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. R/s Gary |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]