[ibis-macro] Re: [ibis-editorial] File name concepts as used in IBIS 6.1

  • From: Walter Katz <wkatz@xxxxxxxxxx>
  • To: <michael.mirmak@xxxxxxxxx>, <ibis-editorial@xxxxxxxxxxxxx>, "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
  • Date: Fri, 21 Apr 2017 21:16:33 -0400 (EDT)

MM,

 

I agree with your assessment. I think the application of when a file
refers to the name of its own file, then it is just "<basename>.<ext>".
<basename> does not have "/", <ext> does not have "/" or ".".

 

When a file is a another file reference within this file, then it is a
"file name" as you defined it.

 

The only subtle point here is .pkg files. .pkg files are not reference by
name in IBIS, but an IBIS file can have access to any .pkg file in the
directory. I think that his was always fundamentally flawed approach, and
a [Component] should be required to list the .pkg files that it is using,
and then .pkg files could be "file name" as you use it. But since we do
not have such a list, then .pkg files must remain in the IBIS directory.

 

Walter

 

Walter Katz

 <mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx

Phone 303.449-2308

Mobile 303.335-6156

From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Friday, April 21, 2017 7:19 PM
To: 'ibis-editorial@xxxxxxxxxxxxx' <ibis-editorial@xxxxxxxxxxxxx>;
IBIS-ATM (ibis-macro@xxxxxxxxxxxxx) <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-editorial] File name concepts as used in IBIS 6.1

 

 

Today's discussion of BIRD189.2 focused on the concept of "file name" (and
variants on the term), and whether it refers to a string that includes an
extension, whether it is simply the pre-extension string, or whether it
includes path information.  As noted by Bob Ross, the BIRD189.2 language
is closely modeled on .pkg and .ebd language in the IBIS document.

 

I conducted a brief set of searches through the IBIS 6.1 specification,
including on the phrases or words "base name", "basename", "file name" and
"filename".  My general findings are shown below, with quotations where
appropriate.  All page numbers refer to the Adobe PDF* version of the
file.  

 

In brief, I believe Bob and Arpad were correct in their statements during
the meeting, and that there is a long-standing inconsistency in how we
refer to files in even pre-3.2 IBIS.  In particular, the usage on pages 9
conflict with the usage on 140 and 154.  The latter two use "filename",
when "basename" would be more consistent with usage elsewhere.

 

Fortunately, I believe we can very quickly make the document completely
consistent by using the phrase "base name" for the non-extension portion
of the string, and "file name" for the full string, appropriately and
distinctly defined, without forcing model or tool changes.  Current BIRDs
could be made consistent with these definitions very easily.

 

Comments are welcome.

 

*       MM

 

basename

--------

p. 9 - In the "GENERAL SYNTAX RULES AND GUIDELINES" section, "basename"
may be up to 40 characters in length, followed by a period and an
up-to-three-character extension

 

base name

--------

p. 213 - "The algorithmic model is responsible for using DLL_ID as the
base name for any data files that the model creates..."

 

filename

--------

p. 140 - regarding .pkg, "filename" refers to base file name without
extension

p. 154 - regarding .ebd, "filename" refers to base file name without
extension

 

file name

--------

p. 9 - "basename" is 40 characters, followed by a period and an
up-to-three-character "file name extension" (so here, file name is
equivalent to basename)

p. 18 - for [File Name], "the file name must use the extension '.ibs',
'.pkg' or '.ebd'.  The file name must be the actual name of the file."

p. 100ff - for [External Model], "file name" implies extension is
included, but the phrase "file name extension" is used several times

p. 120ff - for [External Circuit], "file name" implies extension is
included, but the phrase "file name extension" is used several times

p. 221 - for Supporting_Files, "file name" is explicitly described in
contrast to directory names and paths

 

Other related posts: