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

[Rex Brooks <rexb@starbourne.com>]

I have no problem with this. As I replied to Art, I understand that 
we're looking for a single profile that fulfills the three sets of 
profile requirements. We're doing well in our meetings and working 
through the CAP elements in the worksheet. The last thing I want to 
do is bring this stuff up in the meetings yet.

However, I think we have a big enough group that some of us can take 
a little time and give some thought to some other issues, too. We 
have the mailing list now, so I just want to make use of it.

I'm interested in getting feedback through the list, and, hopefully, 
stimulate some thinking. However, for now I will wait until after the 
1st or after we've made our first pass through the CAP elements.

Cheers,
Rex

At 10:29 AM -0500 12/29/08, Dwarkanath, Sukumar - INTL wrote:
>I agree with Art - we discussed exploring the possibility of a single
>profile as a starting point - if the requirements point us in another
>direction, we should consider it.
>
>Sukumar
>
>
>-----Original Message-----
>From: Art Botterell [mailto:abott@so.cccounty.us]
>Sent: Friday, December 26, 2008 11:54 AM
>To: emergency-cap-profiles@lists.oasis-open.org; rexb@starbourne.com
>Subject: 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 <rexb@starbourne.com>  >>>
>Hi Folks,
>
>I waited until we had our list to start bringing up the issues I
>didn't want to tackle during our first two meetings. We're making
>good progress, so I didn't want to chance getting bogged down in
>issues we probably couldn't answer or decide definitively
>immediately. I think we'll be in a better position to assess the
>probable impact of the decision(s) we take after we finish working
>through the CAP elements in the process we have already started.
>
>However, I did want to raise the issue(s) on the list, where we can
>discuss it without taking up time in our meetings, at least until we
>get a better grip on issues that may well resolve themselves as we
>finish up working through the worksheet.
>
>The first issue to me, as the volunteer editor, is whether we should
>produce a single specification document that covers the three
>profiles we're currently covering, or we should produce three
>documents. There are a number of issues involved in this.
>
>I don't have a preference at this point. I just want to gather our
>thoughts on the issue. It may be easier to have all three for easy
>reference in a single document, or it may be confusing.
>
>My concern is the reader/implementer and the "Conformance" Section I
>mentioned in our last meeting.
>
>For the front matter of the specification or specifications I have
>two versions going simultaneously, one for all three IPAWS Profiles
>and one for EAS alone. I wanted to get a leg up on the work, but even
>with this, it becomes necessary to handle the two documents in
>distinctly different ways.
>
>We could make it an easier read by addressing the profiles as
>separate sections, each with its own Conformance Subsection.
>
>Using a matrix similar to what we did for EDXL-RM and what we are
>working through now, might be helpful, though after working on a
>reference implementation of EDXL-RM that is not quite done yet, I can
>say that that alone is not sufficient, so we will probably want an
>explicit subsection for each profile with the rules as well, to make
>it easier to gather the "Conformance" language (e.g. the MUSTs, MUST
>NOTs, SHALLs, SHALL NOTs, SHOULDs, etc) making those easy to locate
>and double check.
>
>Of course, the schemas are the ultimately normative components, so
>those are what conformance is validated against. It seems to me that
>separate schemas are necessary.
>
>Cheers,
>Rex
>--
>Rex Brooks
>President, CEO
>Starbourne Communications Design
>GeoAddress: 1361-A Addison
>Berkeley, CA 94702
>Tel: 510-898-0670
>
>---------------------------------------------------------------------
>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
>
>
>
>---------------------------------------------------------------------
>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