Re: [emergency-cap-profiles] One v. Several SpecificationDocuments

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