Elysa suggested I provide some thoughts regarding conformance clauses and
standards. By way of background, the OGC has had compliance testing for a number
of our standards for many years. We have recently upgraded the compliance
testing engine (open source) and our members have developed a Compliance
Assertion Language (more on this later). We have recently added tests for 6
existing OGC standards and some profiles of those standards, such as GeoRSS
GML.
Notice we use the word "compliance". We spend weeks arguing whether we
should have "conformance" testing or "compliance" testing. Turns out that there
are very specific semantics associated with the use of those words in the
context of testing a standard or a profile of a standard as to whether it meets
the mandatory elements of the given standard. I should also point out that there
is a big difference between compliance testing and interoperability testing.
Just because an implementation of a standard has tested to be compliant does not
guarantee interoperability - it only increases the probability of
interoperability.
Anyway, we have a "standard" document template for all OGC web service
standards. Annex A is a normative section for describing the abstract
conformance clauses - what we call the Abstract Test Suite. From that
document:
In each Implementation Specification
document, Annex A shall specify the Abstract Test Suite, as specified in Clause
9 and Annex A of ISO 19105. That Clause and Annex specify the ISO/TC 211
requirements for Abstract Test Suites. Examples of Abstract Test Suites are
available in an annex of most ISO 191XX documents. Note that this guidance may
be more abstract than needed in an OpenGIS® Implementation Specification.
The actual ISO document (attached) that
provides guidance on how to specify an ATS is useful but perhaps more detailed
than necessary for use with many interface and encoding standards.
Now, in practical terms what this all
means is that when a group is crafting an interface or encoding standard, such
as HAVE, one has to be very careful about the proper use of the terms "MUST",
"SHALL", etc. Why? Because the ATS (conformance classes) are based on all the
mandatory elements of the standard.
Now, why have an ATS? Well, the team in
the OGC that builds compliance tests uses the ATS to define the testable
assertions that are then documented using the compliance assertion language that
our compliance test engine then uses to test any instance of an implementation
of that standard. If the implementation being tested passes all of the
assertions, which as based on the ATS, then the implementation is deemed
compliant.
So, in terms of Alessandro's email, the
ATS is by definition abstract. Further, definition of the conformance classes in
the ATS is totally application independent. The OGC Compliance Testing
capability is accessible from http://www.opengeospatial.org/compliance .
Hope this helps.
Regards
Carl
----- Original Message
-----
Sent: Friday, September 07, 2007 11:05
AM
Subject: RE: [emergency-msg] RE:
EDXL-HAVE - Conformance Statement
With regard to identifying
conformance targets, I think the best approach is to identify a minimal set of
suitable abstractions for them. In other words, I think we should not
think of a conformance target as being one particular category of real-world
users (of which there could be many and hard to distinguish), but more in
terms of broad (abstract) roles in the use of the standard. I
don't know if "hospital" is a good conformance target--it **may** be, given
that the standard is about hospital availability, and so I have no objections
(in principle) to specifying "hospital" as one of the conformance
targets. I just think we should think in abstract terms (perhaps we are
doing that already, in which case this email of mine is not saying anything
new...).
Alessandro
I agree with the approach. Who is taking the lead?
Elysa
At 07:55 AM 9/7/2007, Rex Brooks wrote:
Hi Elysa,
Michelle,Sukumar,
Alessandro posted a couple of notes on this, with
some urls for WS-I* documents that deal with this.
Given what Mary
said, I think we would be well advised to think through this issue in
terms of:
1-identifying conformance targets, possibly IMO including
hospitals themselves as well as implementations and tools; 2-using the
detailed approach Michelle suggested in Tuesday's meeting which focuses in
on specific "combinations" of MUST conformance statements with some
optional SHOULD statements where to be completely conformant for specific
purposes, such as infectious disease, mass casualties or emergency relief
specific sets of MUST abd SHOULD statements must be implemented as
specified.
I've given it quite a bit of thought and I think Mary is
correct. If we don't do this now, we may end up needing to do it later
followed by another full 60-Day Review, so it is better to dig into this
now and get ti right.
For the EM-Msg SC: We face the same argument
for EDXL-RM with different conformance targets and details. I will bring
it up in today's meeting, but I don't want to spend a lot of time on it. I
just want people to understand that the issue is there, and we need to add
it to the face-to-face agenda.
Cheers, Rex
At 8:29 PM
-0500 9/6/07, Elysa Jones wrote:
We discussed it quite a
bit. Liked the idea of something not too detailed and thought we
would run it by Mary. That didn't go well per her note below and
as far as I know there has been little discussion since. Elysa
At
08:27 PM 9/6/2007, Dwarkanath, Sukumar wrote:
Was any decision made re this, or did you get a
chance to discuss
this? Thanks Sukumar
From: Mary McRae
[ mailto:marypmcrae@gmail.com] On Behalf Of
Mary McRae Sent: Tuesday, September 04, 2007 2:01
PM To: 'Elysa Jones' Cc: Dwarkanath, Sukumar; 'Rex
Brooks'; 'Michelle Raymond' Subject: RE: EDXL-HAVE -
Conformance Statement While it probably meets the “letter of the law”, I’m not quite
sure what “supports” really means and how someone would be able to
determine whether or not their application truly conforms. I remember
an earlier concern around CAP – someone stating that they
implemented/were using CAP but they didn’t allow for one or more of
the optional elements. The TC felt strongly that the implementation
should not be able to say that it conformed to CAP. You want to make
sure that the conformance statement covers exactly what it means to
say your application conforms to the EDXL-HAVE specification,
including specific references to other specifications and their
versions as appropriate. I saw a mention of doing something really
simple this time around and then working on it later, but that will
then force another public review round. As always, I urge the TC to
take the time to “get it right” now. Of course the
decision is up to the TC; as long as the conformance section meets the
basic requirement I have no reason to hold it back. All
the best, Mary From: Elysa Jones [ mailto:ejones@warningsystems.com] Sent:
Tuesday, September 04, 2007 12:46 PM To: Mary
McRae Cc: Dwarkanath, Sukumar; Rex Brooks; Michelle
Raymond Subject: EDXL-HAVE - Conformance
Statement Can
you tell us if the following is sufficient for EDXL-HAVE conformance
section? Elysa
4. CONFORMANCE
An implementation is a conforming
EDXL-HAVE if the implementation meets the conditions in Section
4.1. 4.1
CONFORMANCE AS
EDXL-HAVE
1. Supports the use of EDXL-DE, or a
similar distribution element
2.
Supports the syntax and
semantics in the Data Dictionary (Sec 3.2)
3.
Supports the defined EDXL-HAVE schema (attached
artifact) This
electronic message transmission contains information from SRA
International, Inc., which may be confidential, privileged or
proprietary. The information is intended for the use of the individual
or entity named above. If you are not the intended recipient, be aware
that any disclosure, copying, distribution, or use of the contents of
this information is strictly prohibited. If you have received this
electronic information in error, please notify SRA immediately by
telephone at
866-584-2143.
--
Rex Brooks President,
CEO Starbourne Communications Design GeoAddress: 1361-A
Addison Berkeley, CA 94702 Tel:
510-898-0670
|