emergency-cap-profiles — archive

[Art Botterell]

Rex - My understanding is that the SC's already agreed that, a) a single profile, if possible, would be preferable on grounds of interoperability and simplicity, and b) we'd not yet found any reason multiple profiles were necessary. As you'll recall, we drilled into that at some length on our first call. The question will remain open until we've looked at all the requirements, of course, but so far nobody's made any sort of case for multiple profiles. Also, I'm not sure a schema is inherently any more normative than the data dictionary or any other normative element of a specification. A schema defines syntax in terms of element types and relationships, but it doesn't specify the semantics of what individual elements' values mean in the application context. That's what makes "conformance" testing more complicated than it sounds; simple XML well-formedness and validity are necessary-but-not-sufficient to guarantee compliance with CAP (or CAP Profile) semantics. So far, what we've identified as additional constraints to be specified in a Profile are occasionally syntactic (e.g., making certain optional elements mandatory) but mostly semantic (specifying the meaning of the values which the elements can/must contain.) I'd suggest waiting until we know what the Profile actually needs to say before deciding how to say it. There's certainly a lot of OASIS boilerplate that will have to be included, but since I think we're breaking new ground here (has OASIS ever generated a "profile" document before?) I'm thinking we'll want to preserve our freedom to respond to the actual requirements of the project. - Art >>> Rex Brooks