[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: EDXL-DE 2.0 for the F2F - Objectivity, Subjectivity and Interpretation.
Don, As far as your question
about using different wording about OPTIONAL, MAY use multiple… (and
other related issues) (From our Engineer) RFC 2119 defines these
words, and they are in common use in other RFCs and various standards
documents. These words do *not* by themselves indicate subjectivity. If the spec says "this
element is OPTIONAL," then the element is optional. A message containing
the element conforms. A message not containing the element conforms. A
mechanical system can make that determination. Every test engineer will arrive
at the same conclusion. Similar logic holds for
phrases like "MAY use multiple." Take the <digest>
element inside EDXL-DE. According to the spec, it's an xsd:string, which is
zero or more "printable" characters, such as "A,"
"/," "$," etc. According to the spec it calculated using
the Secure Hash Algorithm SHA-1. SHA-1 produces a 160-bit output. Right off
the top of my head, I can come up with half a dozen ways to encode those 160
bits into an xsd:string, most of which could be "the most obvious way."
What did OASIS intend? Did OASIS intend something else? What if a vendor comes up
with a way we didn't think of? Does the message conform? No mechanical
solution can accommodate that vendor; different test engineers will arrive at
different conclusions. Take the
<combinedConfidentiality> element inside EDXL-DE. The spec says
REQUIRED, MUST be used once and only once. There's not much subjectivity
there, is there? Then again, the spec also says "...the most restrictive
of the <confidentiality> elements..." So if one
<confidentiality> element contains "I hope no one finds out,"
another contains "don't tell my sister," and a third one contains
"φος" (the Greek word
for "light"), which one is the most restrictive? It comes down to the
question of every engineer coming to the same
conclusion: If there's room for
interpretation, then it's subjective. Even if there are
multiple choices, but no wiggle room within any of the choices, the decision is
objective. Consider the <mimeType> element. An infinite number of
strings are MIME type, but any given string either is a MIME type or it's not. My reply to Donald
would be that those words are fine. Additionally,
however, I would note that his proposed statement about radii is ambiguous
until a "normal signed or unsigned int."
is defined. 25 years ago, a
"normal unsigned int" was 16 bits wide. 15 years ago, it was 32 bits
wide. Today, it is 64 bits wide. Unless you've been working on CDC mainframes
for 30 years, in which case it has always been 30 or 36 bits wide.
Coincidentally, a unsigned 16-bit int with a value less than the maximum value
of a signed 16-bit int isn't too far off: that would limit
radii to 32767 kilometers, which is about 80% of the Earth's circumference. Timothy
D. Gilmore | SAIC Sr. Test Engineer | ILPSG | IPAWS CA / NIMS STEP phone: 606.274.2063 | fax: 606.274.2025 mobile: 606.219.7882 |
email: P Please consider the
environment before printing this email. From: McGarry, Donald
P. [mailto:dmcgarry@mitre.org] Tim- I wholeheartedly
agree! I did bring this up
for discussion earlier and we agreed that a circle should be <circle>lat’,’lon<space>radius</circle> Which makes comment
1 and the example wrong (extra space in both between the lat and lon). This is on the
issues list for 2.0. I will add the point about the radius, because as
stated it should be an unsigned
integer with a maximum value less than that of a normal signed or unsigned int. Are you suggesting
that we use different wording for the OPTIONAL, MAY use multiple? That
was a little confusing to me at first, so input would be appreciated. I have added these
topics to the issues list From: Gilmore, Timothy
[mailto:TIMOTHY.D.GILMORE@saic.com] All, Some of the things we look at are
objectivity and subjectivity due to our accreditation under the American
Association for Laboratory Accreditation (A2LA) for NIMS STEP and IPAWS
Conformity Assessment (CA) testing. Many elements under the OASIS EDXL suite of
standards including CAP use words such as “SHOULD” and
“MAY” which are clearly subjective in nature. One of our engineers
pointed out some issues that we should keep in mind when going over the EDXL-DE
2.0 document during the F2F. For CAP: What we're looking for are rules or constraints that are
open to interpretation, or not fully specified, rather than being completely
"nailed down." For example, consider the <circle> element. Is
the following a "correct" <circle> element? <circle> 0, 0, 150000000 </circle> It certainly fits the descriptions in that element's
comments: (1) it's in the form "latitude, longitude, radius";
(2) the central point conforms to WSG84; (3) the radius value is expressed in
kilometers; and (4) it is a properly escaped XML string. Then again, the radius of the circle is approximately the
distance between the Earth and the Sun. Note that the given definition
includes the word "geographic" (twice!) and that the center of the
circle is specified as longitude and latitude, all of which indicates to me
that the circle ought be to Earth-bound. Someone else may interpret the
standard differently, and the standard doesn't put a real limit on the radius
of the circle. The point is that the standard doesn't really specify enough
for a tester to determine whether or not a <circle> element is
conforming. The tester has to make up his (or her!) own rules to
complete the test. Multiple testers will certainly come to different
conclusions, and all will be correct to within the subjectivity allowed by the
standard. (And that all said, note that the given example doesn't
match the form given in comment 1; the comma between the longitude and the
radius is missing. Since all of section 3 of this standard is normative,
this is a bug in this standard.) For another example, consider the <senderRole>
element. The standard says "OPTIONAL, MAY use multiple."
Despite the words "OPTIONAL" and "MAY," an individual
tester can determine without a doubt whether a given message contains zero or
more <senderRole> elements, and an infinite number of testers (all else
being equal) will come to exactly the same conclusion. Perhaps something to think about at the
F2F. Thanks, Timothy
D. Gilmore | SAIC Sr. Test Engineer | ILPSG | IPAWS CA / NIMS STEP phone: 606.274.2063 | fax: 606.274.2025 mobile: 606.219.7882 |
email: P Please consider the
environment before printing this email. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]