OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-cap-profiles message

[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]