One v. Several Specification Documents

[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