types of conformance

> > Can you rephrase that into a constraint on products?  That's where you
> > lost me the first time through. 
> 
> I am not sure if "constraint" is the right term here, but whatever.

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.)

> > > 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.

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".)

> > > To exchange a ruleset, R, between RL1 (with mapping f1) and RL2 (with map
> ping
> > > f2), you do inverse-of-f2(f1(R)). If f1(R) is not in the co-domains of
> > > f2, you get an exception.
> > > 
> > > If the vendors of RL1 and RL2 have sufficiently good technical people, th
> en
> > > they should be able to describe precisely what the co-domains of f1 and f
> 2,
> > > then it would also be possible to describe the co-domain of f1 composed
> > > with the inverse of f2. In this way you, as a user, would know what you c
> an
> > > or cannot exchange. But if those vendors don't have good technical people
> > > then no big deal. Getting an exception is good enough.
> > 
> > I don't think getting an exception is good enough.
> 
> Vendors who can properly define their sublanguages will provide better
> descriptions.

Yes -- they are doing that, iteratively, as part of the RIFRAF process,
in theory.  We've just started that process....

> > I think users need
> > to know when they buy a product which RIF dialects it fully implements.
> > You'd agree, at least, that users would like that, right?   (Better to
> > know the limitations at purchase time instead of run-time...)
> 
> Now you are talking about "implements" vs. "complies".
> This is also what Bijan was aiming at, I think. 

As far as I can tell, Bijan and I are in agreement.  He seems to be
explaining it better than I am, though.  :-)

> See my response to him
> http://lists.w3.org/Archives/Public/public-rif-wg/2006Dec/0098.html
> 
> I agree that there should be two notions here. Not sure which should be
> called "compliance". I think the second one should be called "implements"
> and not "complies". (Hope the quotes don't scare you this time around :-)

How about this:

   "RIF Structural Conformance" is the notion you're proposing, along with
   some bits about syntax and extensibility.

   "RIF Core Conformance" means you can turn all RIF Core rulesets into
   native rulesets, and round-trip them back to RIF Core, and tell users
   if that are using any features which you can't translate to RIF Core.

   "RIF Dialect-N Conformance" means (Same as RIF Core Conformance, for
   that dialect.

So then it's possible to say something is conformant to "RIF Structure"
because, for instance, it's conformant with a dialect that is not *yet*
standard.

(I'm fine with other words in the place of "structure" -- that's just
the best I could think of.)
    
     -- Sandro

Received on Monday, 18 December 2006 19:36:38 UTC