← Prev in month ← Prev in thread
Next in thread → Next in month →

Re: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas - What is a profile

From
"Darl Qeed"
Date
2010-03-15T21:05:10+00:00
ID
A992409814974D86A3FC52628090C4E9@CarlandSusieOf
Thread
Re: [emergency] HAVE Conformance vs. Documentation vs. Released Schemas - What is a profile
Good points.

 

As I read the emails on this topic, I have to ask: What is the OASIS 
definition of a profile? The OGC traditionally used the ISO/IEC 10000 Part 1) 
directives as guidance. Them last year, the Members took the bull by the horns 
and worked to very clearly and consistently define what we in the OGC mean by 
profile. While the simple definition is that a profile is a restricted subset of 
a standard, one really needs to look at the conformance classes (which are tied 
back to requirements). Lee has specified a set of requirements which actually 
would tie very nicely to conformance classes.

 

The OGC definition of all of these terms are found in a public OGC policy 
document titled, "The Specification Model — A Standard for Modular 
specifications".

 

From that document, a profile is a "standard consisting of a set of 
references to one or more base standards and/or other profiles, and the 
identification of any chosen conformance test classes, conforming subsets, 
options and parameters of those base standards, or profiles necessary to 
accomplish a particular function."

 

Just to stir the pot a bit more :-)

 

Cheers

 

Carl

 

  
----- Original Message ----- 

  
From: 
  Lee 
  Tincher 

  
To: 'Gary Ham' ; 'Paulsen,Norm 
  [Ontario]' 

  
Cc: 'McGarry, Donald P.' ; 'David RR Webber 
  (XML)' ;  
  ; 'Dwarkanath,Sukumar - INTL' 

  
Sent: Saturday, March 13, 2010 10:21 
  PM

  
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.*
(* may be thought of as a “constraint schema” against the 
  standard)

  
·         
  A HAVE Haiti 
  Profile message may add to required element 
  definitions.*
(* only to extend or interpret the 
  definition)

  
·         
  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:] 
Sent: Tuesday, March 09, 2010 4:45 
  PM
To: Paulsen,Norm [Ontario]
Cc: McGarry, Donald P.; 
  David RR Webber (XML); ; Dwarkanath,Sukumar - 
  INTL
Subject: Re: [emergency] HAVE Conformance vs. Documentation vs. 
  Released Schemas

  
 

  
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:] 
Sent: March 9, 2010 4:24 
  PM
To: Paulsen,Norm [Ontario]
Cc: McGarry, Donald P.; 
  David RR Webber (XML); ; 
  Dwarkanath,Sukumar - INTL
Subject: Re: [emergency] HAVE Conformance 
  vs. Documentation vs. Released Schemas

  
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:] 
Sent: March 9, 2010 3:52 
  PM
To: Paulsen,Norm [Ontario]
Cc: McGarry, Donald P.; 
  David RR Webber (XML); ; 
  Dwarkanath,Sukumar - INTL
Subject: *****SPAM***** Re: [emergency] 
  HAVE Conformance vs. Documentation vs. Released Schemas

  
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

  

  
 

  
 

  

  

  
Gary 
  Ham

  

  
http://grandpaham.com

  

  
703-899-6241

  

  
 

  
 

  
 

  
 

  

  

  
Gary 
  Ham

  

  
http://grandpaham.com

  

  
703-899-6241
← Prev in month ← Prev in thread
Next in thread → Next in month →