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).
>
>--
>
>--
>
>---------------------------------------------------------------------
>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
