Re: types of conformance

Sandro Hawke wrote:

> Well, right, the technical term here, in the language of standards (at
> W3C at least), is "conformance".  Something is said to conform or not
> conform to a specification.  We (RIF-WG) have to decide on a class of
> products (eg "rule engines") and what it means to have a rule engine
> "conform" to "RIF Core" (or RIF in general, perhaps, if that label is
> also useful).   (We'll also want to define conformance for other kinds
> of software which handles RIF, like editors, but I'm not worried about
> that right now.)

In my experience, the first concern is to define "conformance of a document" 
or "conformance of a resource".  We must specify what a well-formed and 
useable RIF XML entity looks like.  We must also specify (within some limits) 
what it means.  And since we will specify certain valid subsets, we can talk 
about conformance of a resource to particular subsets/dialects of the RIF XML 
language.

Then we can talk about conformance of a tool that produces one of those. 
Essentially, a producer tool conforms when what it produces conforms to the 
document conformance spec, and the intent of the exchange document is 
consistent with what we say it means.  And a producer can claim conformance to 
particular subsets/dialects of the language.  (This would be unnecessary for 
producers, except that the interpretation rules may depend on the advertised 
subset, and some combinations of "RIF dialects" may have no interpretation 
when lumped into a single bag.)

And then, maybe, we can talk about conformance of a tool that consumes one of 
those RIF resources.  The problem with this "class of conformance" is that we 
can't really specify what such a tool will do -- we can only specify that it 
must interpret the RIF resource as specified in this Recommendation, and that 
whatever actions it takes that may be driven by that resource must be 
consistent with the interpretation provided in this Recommendation.  Here 
conformance to a dialect means that the tool is not required to accept RIF 
resources that do not conform to one of the specified dialect(s)/subset(s) to 
which it claims conformance.

>>>>To avoid a
>>>>misunderstanding, 1-1 means into, not onto. The mapping may only map a
>>>>subset of the RL for a whole number of reasons.
>>>
>>>I'm okay with saying only a subset needs to be mapped -- every rule
>>>language is likely to have features that go beyond the nearest RIF
>>>Dialect -- but I think users need to be warned (at least in "standards
>>>mode") when they create rules outside the mapping.  Are you okay with
>>>that?
>>
>>This is for the vendor to do. Vendors are the ones who define the mapping
>>for each particular product.

Exactly.  We cannot specify what a conforming RIF producer does with respect 
to some other unspecified rules language.  There there be dragons.  We can 
define what the RIF language(s) can convey, full stop.  What the producer tool 
started with is out of our scope.  What some RIFWG participant's tool starts 
with will presumably color his/her position on what the RIF XML must support, 
but the definition of conformance stops with what it does support.

> I don't agree.  That's part of what RIF-WG is chartered to do.  The
> market more benefits from there being a small number of standard
> languages/dialects/profiles/mappings/feature-sets/whatever-you-call-them.
> (I think we've agreed to call them "RIF Dialects".)

I think Sandro is addressing a different problem.  If RIF is "extensible", and 
a conforming producer can add stuff that only one of its friends will 
understand, then it is reasonable to distinguish a "strictly conforming" 
resource from a "conforming extended resource".  And then, if it is seen to be 
in the interest of some user community, the community can require that its 
tools (be able to) produce "strictly conforming RIF resources".

Should we require that a conforming tool be able to inform a user that the 
ruleset he is trying to exchange will need an "extended resource"?  In the 
last 40 years, this has been a hot button for the Fortran, COBOL, SQL and C 
languages, to my knowledge, and I'm sure there are other cases.  It is my 
personal opinion that this is simply the last bastion of people who don't 
really want to allow "extended resources" to conform at all.  So they want the 
tool to have a "diagnostic" that tells the user his resource does not strictly 
conform to the standard, partly in the hope that they will annoy him into 
fixing it, but mostly in the expectation that his community will regard that 
as diagnostic as an indication that his ruleset is "non-conforming" (and 
"unacceptable").

If strict conformance is a critical idea to enough of the target user 
community, then we probably should have such a requirement.  But unlike OWL, 
there is no provable bounded behavior for most useful rules languages, and 
many of the "extensions" are about getting bounded behavior from a particular 
engine design.

>>>>To exchange a ruleset, R, between RL1 (with mapping f1) and RL2
>>>> (with mapping f2),

This is a critically important idea in the rules language community at large, 
but it is WAAAAY outside of what the RIFWG can actually specify.  We can 
specify the exchange language(s), full stop.  Experts can specify injections 
from language RLx into RIF exchange languages and embed them in the tools they 
develop to do that.  Experts can also specify injections from RIF languages 
into their favorite RLy languages and develop tools to do that.  That is all 
very nice, and the availability of such mappings may be valuable when you are 
considering using a particular tool in an environment of RIF exchanges. 
BUT...it has nothing directly to do with what the RIF WG standardizes.

And IMNSHO, if we *require* every tool to specify the inbound mapping (RIF to 
RLx) for whatever language it internalizes, *most* of those published mappings 
will be difficult to follow, ambiguous, inaccurate or simply wrong.  Because, 
among other things, we have no standard language in which to specify the 
mappings.  But the real problem is: As soon as there is not a 1-to-1 feature 
correspondence between RIF language X and RLy, the mapping becomes 
pattern-to-pattern, and how the tool actually does the pattern recognition 
becomes an issue.

In the interest of delivering a useable specification in finite time, I 
suggest that the RIFWG use its knowledge of mappings to condition the choices 
for capabilities, syntax and semantics of the RIF subset languages, and stop 
there.  The rest of the mapping technology issues will beget many academic 
degrees and make certain toolsmiths richer than others, and that is as it 
should be.

-Ed

-- 
Edward J. Barkmeyer                        Email: edbark@nist.gov
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263                Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263                FAX: +1 301-975-4694

"The opinions expressed above do not reflect consensus of NIST,
  and have not been reviewed by any Government authority."

Received on Monday, 18 December 2006 21:13:48 UTC