[ibis-editorial] Re: Quick editorial issue notes

  • From: "Bob Ross" <bob@xxxxxxxxxxxxxxxxx>
  • To: <michael.mirmak@xxxxxxxxx>, <ibis-editorial@xxxxxxxxxxxxx>, <ibis-quality@xxxxxxxxxxxxx>
  • Date: Wed, 6 Apr 2016 14:10:56 -0700

Michael,

 

We will discuss this.

 

Bob

 

From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Wednesday, April 06, 2016 12:44 PM
To: Bob Ross; ibis-editorial@xxxxxxxxxxxxx; ibis-quality@xxxxxxxxxxxxx
Subject: [ibis-editorial] Re: Quick editorial issue notes

 

Bob,

 

Understood and thanks.  Col_headings (not Col_Headings?  J) would work just
fine.  I would personally prefer that. 

 

1)      "Sub-params" be changed to "Subparams"; or "subparameters" in the
text be changed to "sub-parameters"

2)      The column header and subparameter concepts be separated clearly in
the specification.  

 

I call on the IBIS Quality Task Group to assess the parser impact of
changing the interpretation of column headers from "subparameters".  J

 

One minor tweak to my general subparameter principle: If it helps, you can
think of "subparameter" as referring to data which is a subordinate part of
a keyword, *has its own token*, and which appears on its own line.
Therefore, Fork and Endfork are subparameters, despite having no arguments,
but signal_name entries are not.  If we fix the [* Matrix] and pin-related
definitions, this principle is consistent and iron-clad.

 

-          MM

 

From: Bob Ross [mailto:bob@xxxxxxxxxxxxxxxxx] ;
Sent: Wednesday, April 06, 2016 11:55 AM
To: Mirmak, Michael; ibis-editorial@xxxxxxxxxxxxx
Subject: RE: [ibis-editorial] Quick editorial issue notes

 

Hi Michael,

 

Good catches - especially for [* Matrix].  We can remove the Sub-Params
line, but

we will have to add the rule that each of the keywords must be followed by
one

of the three argument listed arguments.  The Example shows this.

 

We have to be careful and also update the

3.1 Keyword Hierarchy where the items (in parenthesis) are both
sub-parameters and

column headings.  For legacy reasons, and document administration, and
possible

ibischk6 parser message consistency, we should still keep the word
Sub-params for

column headings.

 

Adding Column_Headings: might create alignment problems with the keyword
format.

 

If we do this, we have to be careful with other verbiage and also consider
an abbreviated

form such as Col_headings.

 

I have to think about this more.

 

Bob

 

 

 

From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Wednesday, April 06, 2016 10:23 AM
To: ibis-editorial@xxxxxxxxxxxxx
Subject: [ibis-editorial] Quick editorial issue notes

 

 

Per a discussion in the Interconnect Task Group today, plus other messages
recently received, I wanted to note a few key editorial issues we need to
resolve for the next IBIS document:

 

1)      There is a list of known IBIS 6.1 issues available at
http://www.ibis.org/ver6.1/ver6_1_known_issues.txt ;(note that this is being
updated with some new entries, so check back often).  Most of these will be
tackled as part of our next editorial "scrub" of the document. 

 

2)      As noted today, the subparameter concept is (somewhat)
inconsistently used in the document.  A minor issue is that the word
"subparameter" is used in the text, but the abbreviation "Sub-param" is used
as part of the keyword definition headers.  A more significant problem
occurs under several keywords, where column headers are incorrectly referred
to as "subparameters".

 

a.       For [Pin Mapping], columns of data for the bus labels are
improperly referred to as "subparameters" in the text, but also as "columns"
with "entries"; the column header names are listed under the keyword
definition as "Sub-params".  

 

b.      For [Series Pin Mapping], the column header names are listed under
"Sub-params" but the word "subparameter" is fortunately never used to refer
to them.  This also occurs for [Pin], [Diff Pin], [Pin List], [Repeater
Pin], [Pin EMI], and [Pin Domain EMI].

 

c.       For [Resistance Matrix], [Inductance Matrix], [Capacitance Matrix],
the word "subparameter" is incorrectly used to refer to the keywords'
arguments and the argument choices are incorrectly listed under
"Sub-params".

 

In general, these should be relatively easy to fix by adding a new
definition line called "Columns" for all the keywords except [* Matrix] and,
where needed, changing "subparameter" to "column" or "entry" (with plural
variants) in the corresponding text.

 

If it helps, you can think of "subparameter" as referring to data which is a
subordinate part of a keyword and which appears on its own line.

 

Comments?

 

-          MM

 

Other related posts: