Model update

["Joel M. Halpern" <[e-mail]>]

Alia Atlas, on behalf of the Routing ADs, did a thorough review of the
Forces model document.  For most of her comments, the correction is
largely an editorial matter of ensuring that the words line up with the
WGs agreed meaning.

One item she noted likely requires an actual change to the XML of the
schema.  Specifically, in the section on backwards compatibility we say
that an FE should support a backwards compatibility mode where it allows
a CE to configure an LFB of a derived class that the FE supports as if
it were of the parent class.  This comes up if the FE does not normally
permit creation / manipulation of LFBs of the parent class, or if the FE
has instantiated the LFB instance without the CEs intervention (either
by doing os itself, or under instruction from an earlier controlling CE.)
There are two issues.  Firstly, the CE is going to try to use a
different type/instance ID pair for this LFB instance than the FE is
expecting.  Secondly, we do not mandate that the FE permit this
substitution (because we can not foresee all possible cases.)

My proposed correction to address this is to add to the FE Object LFB,
in the table of supported LFB Classes, in each entry describing a class,
a list of permitted parent substitution classes.  This will allow the CE
to know that the unknown class is derived, and that the CE may just use
the parent class if it needs to.  The implication of such a substitution
list is that the FE must insure that IDs are unambiguous across entries
which may share an LFB Class ID that is used to reference them.

So I want to check that the WG is comfortable with this addition.
I am going to try to get this in with the other changes before the
deadline, and remove it if the WG tells me to, as the problem seems real
to me.

Yours,
Joel M. Halpern