OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-cap-profiles message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [emergency-cap-profiles] profile proliferation

Thanks Art,

I agree that the real answer is to move CAP toward EDXL integration, 
and I get the sense that that is what the next step will be, and that 
we'll probably get started on it sooner rather than later. For now, 
though, I think we're doing okay on the work before us.

I also agree that encouraging more CAP Profiles is not wise, and 
thinking through it is convincing me of that the more I study it.


At 10:56 AM -0800 1/7/09, Art Botterell wrote:
>Again I'd stress that profiles aren't devised by message originators for
>their own purposes, but rather are used to document special requirements
>of particular message consumers.  If a particular consumer or consumers
>(e.g., IPAWS) wants to specify what it/they need(s) to see in a message,
>it/they can publish a profile.  Then originators may choose to implement
>or not implement that profile, depending on how important satisfying
>that particular consumer or consumers is to them.
>Strictly speaking a data dictionary defines semantics, while a schema
>specifies syntax.  (In practice a data dictionary may mention syntactic
>rules as well, but the schema is generally viewed as definitive on
>syntax.)  So a profile might include a data dictionary, a schema or
>depending on what's being constrained.  (Or even "neither" if the
>particular constraints in question are simple enough to be described
>without resorting to a full-blown dictionary or schema.) 
>For example, a rule that there can only be one info block (NOT a
>recommendation, only an example!) might be expressed best in a schema,
>whereas a rule that says info blocks shall only be used for versions of
>the same message in different languages (again, only for example) would
>be a semantic constraint best addressed in data dictionary style.
>As for a dictionary of agreed semantics within an application domain,
>that would need to be defined by the subject matter experts.  For
>example, we here aren't seismologists.  That's how EDXL approaches
>various versions of this same problem, and that's why I think the real
>answer here is to move CAP toward EDXL integration without perpetrating
>in any more profiles than are absolutely necessary in the meantime.
>- Art
>Art Botterell, Manager
>Community Warning System
>Contra Costa County Office of the Sheriff
>50 Glacier Drive
>Martinez, California 94553
>(925) 313-9603
>fax (925) 646-1120
>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:

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]