[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: One v. Several Specification Documents
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]