[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [emergency-cap-profiles] One v. Several SpecificationDocuments
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]