[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. Cheers, Rex 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: >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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]