[ibis-macro] Re: IBIS Draft BIRD147.2

  • From: "Bob Miller" <dmarc-noreply@xxxxxxxxxxxxx> (Redacted sender "bob.miller" for DMARC)
  • To: Mike LaBonte <mlabonte@xxxxxxxxxx>
  • Date: Fri, 30 Sep 2016 13:41:17 -0600

OK, Mike, that's a rational explanation for the re-direction in the
language. I concur with your approach.

As I am currently wading aimlessly through the [External Model] forest in
IBIS ver6_1.pdf, I am sensitive to anything which requires a bigger
associative cache in the reader's wet-ware. Especially as this aging fossil
is running out of memory-repair links therein.

Regards,

Bob

On Fri, Sep 30, 2016 at 1:32 PM, Mike LaBonte <mlabonte@xxxxxxxxxx> wrote:

Yes, but I feel better about making some IBIS keywords dependent on the
presence of other IBIS keywords, because these can be clearly and crisply
stated with a single word. It also gives IBISCHK a clear mandate to
complain about missing BCI_ID if BCI_Protocol is present, for example.
IBISCHK doesn’t really know if the model supports BCI, so BCI_Protocol
becomes the primary indicator of that. If they all are required “if the
model supports any BCI protocol” then IBISCHK has nothing in the spec to
instruct it.



So the message for missing BCI_ID might be:



ERROR – Parameter BCI_ID is absent but required because BCI_Protocol is
present



And the message for missing BCI_Protocol where other BCI parameters are
present might be:



ERROR – Parameter BCI_ID is illegal because BCI_Protocol is not found



That raises the point that BCI_ID, BCI_State, and BCI_Training_UI should
have clauses in the BIRD disallowing them unless BCI_Protocol is present.
Then IBISCHK would have a clear mandate.



Mike



*From:* Bob Miller (APD) [mailto:bob.miller@xxxxxxxxxxxx]
*Sent:* Friday, September 30, 2016 3:10 PM
*To:* Mike LaBonte
*Cc:* Bob Ross; IBIS-ATM
*Subject:* Re: [ibis-macro] Re: IBIS Draft BIRD147.2



Mike --

if this is postulated:

BCI_Protocol must be present if the model supports any BCI



Doesn't your language logically reduce to:



BCI_Protocol must be present if the model supports any BCI
BCI_ID must be present if if the model supports any BCI
BCI_State must be present if the model supports any BCI
BCI_Training_UI must be present if the model supports any BCI

Regards,

Bob





On Fri, Sep 30, 2016 at 1:03 PM, Mike LaBonte <mlabonte@xxxxxxxxxx> wrote:

To summarize, although each new keyword has:

        Required:       No, and illegal before AMI_Version 7.0

A line is added such as:

        BCI_Protocol must be present if BCI protocol is present.
        BCI_ID must be present if BCI protocol is present.
        BCI_State must be present if BCI protocol is present.
        BCI_Training_UI must be present if BCI protocol is present.

Maybe we should try to avoid using "present" twice in each sentence. One
way to do this:

1) Change the first one to:

        BCI_Protocol must be present if the model supports any BCI
protocol.

2) Change the others to:

        BCI_ID must be present if BCI_Protocol is present.
        BCI_State must be present if BCI_Protocol is present.
        BCI_Training_UI must be present if BCI_Protocol is present.

Mike


-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Thursday, September 29, 2016 9:15 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] IBIS Draft BIRD147.2

Mike LaBonte and All

Attached is a draft revision of BIRD147.2 with the YYI Required and
Default column modified per our discussion.

Corresponding statements are inserted as a sentence in the Definition
portion of each changed parameter.

If this is ok, Mike could up upload this to the Open Forum site..

Bob

--

Bob Ross
Teraspeed Labs
http://www.teraspeedlabs.com
bob@xxxxxxxxxxxxxxxxx
Direct: 503-246-8048
Office: 971-279-5325

---------------------------------------------------------------------
IBIS Macro website  :  http://ibis.org/macromodel_wip/
IBIS Macro reflector:  //www.freelists.org/list/ibis-macro
To unsubscribe send an email:
  To: ibis-macro-request@xxxxxxxxxxxxx
  Subject: unsubscribe



Other related posts: