Re: [emergency-cap-profiles] profile proliferation

[Rex Brooks <rexb@starbourne.com>]

Hi Jacob,

I think we need to be very careful about how we define a profile. 
The one we are working on is limited to three IPAWS exchange partner 
systems. As long as it can do that without doing damage to the base 
specification or opening CAP up to more problems than it solves, then 
I think its on fairly solid ground. The discussion in the TC meeting 
brought up a number of points that I am still thinking through. The 
best thing we have going for us is the level of participation in the 
SC, so we ought to be able to make a good job of it.

I think Elysa was right about the SC's charter being perhaps broader 
than it ought, and this set of questions illustrates that. However, 
the TC can reconsider our purpose and deliverables. Right now we are 
pretty constrained so an excessively broad scope is not a big problem 
yet.

In a sense, I'm glad that the issue of scope for the SC was brought 
up because we will need, at some point, to wrestle with whether or 
not the SC should concern itself with those broader issues of 
profiles for CAP in more general terms. I think that's the context 
where a discussion of a collection of custom parameters would be most 
appropriate.

When the EAS-specific nature of the task at hand was put into the 
larger IPAWS perspective, these broader issues were a logical 
consequence. However, I think that for now, until we have worked 
through the CAP elements, we should put those issues to the side, so 
that we don't confuse ourselves by mixing the general with the 
specific. However, I think that is just for now.

After we get this task nailed down a bit more, we can, if we choose, 
engage in the broader discussion but I think the next TC meeting is 
the best place for that. Of course, we can still discuss it on the 
list here, and see if we can clarify the concerns for that next 
conversation.

It looks to me like the MSG SC Recommendation for a second CAP v1.1 
Errata to shoehorn the "Avoid" responseType and other minor 
non-substantive issues is not finding a lot of support. So that may 
be revisited, or the TC may just decide to launch work on CAP 2.0.

The example below actually demonstrates a way in which EDXL-DE could 
be used to disambiguate between or map "Mag" and "Magnitude" as long 
as the valueNames are published in valid ValueListURNs by their 
respective agencies. That and other concerns that might otherwise end 
up being proposed as profiles, can be more easily handled by 
combinations of keywords, distributionTypes, and contentObjects.

Of course EDXL-DE also needs to be versioned to v1.1 based on what 
we've learned and are continuing to learn about its use.

Cheers,
Rex

At 1:40 PM -0500 1/6/09, Jacob Westfall wrote:
>Hi,
>	An important concern was raised in today's call about 
>profiles and their potential proliferation.  This speaks not only to 
>the definition of a profile, but also to the criteria that should be 
>established to determine what profiles the SC decides to consider 
>for adoption.
>	For example we have developed several dozen profiles although 
>we use the term layer.  Many are implementation specific, some speak 
>to presentation, others have some data in them, etc.  There are only 
>a small number that I would consider meeting the adoption level for 
>the SC.  So in defining a profile are there different types of 
>profiles?  Is there a different name used for "profiles" that do not 
>go through the SC but are still similar in nature?
>	I used the example of border alerts but a more important one 
>would be earthquakes.  Reviewing any USGS CAP alert you notice a 
>number of custom parameters in use.  Typically this is information 
>that may be found in the text description that is also being singled 
>out for parameterization as well.  If this was just for USGS only 
>then fine.  But the presumption is this information is also useful 
>for others and should therefore be documented somehow to ensure 
>other systems can interoperate.  But earthquakes aren't just a USGS 
>only thing, other agencies and countries are naturally involved.  So 
>if agency X uses a valueName of Mag and USGS uses Magnitude for the 
>same values, interop suffers when these two agencies decide to share 
>messages with each other, or the rest of the world.  This is where 
>an SC level profile might come in that is used by all earthquake 
>issuing authorities.
>	So this leads to multi-profile alerts such as when the USGS 
>issues their earthquake alert, it will include IPAWS profile 
>components (US alert system specific) and Earthquake profile ones as 
>well (international and inter-agency specific).
>
>--
>jake@jpw.biz
>--
>
>---------------------------------------------------------------------
>To unsubscribe from this mail list, you must leave the OASIS TC that
>generates this mail.  Follow this link to all your TCs in OASIS at:
>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


-- 
Rex Brooks
President, CEO
Starbourne Communications Design
GeoAddress: 1361-A Addison
Berkeley, CA 94702
Tel: 510-898-0670