Revisiting this, I think Michael pursues a good <pun>path</pun> in seeking
other standards to follow. The boost.org naming system has indeed been
adopted by C++ <http://en.cppreference.com/w/cpp/filesystem/path> , which
defines a “file name” as having no directory path. I find 42 instances of
“file name” and 2 of “File name” in IBIS 6.1, and most of these are used in
reference to a file name with no directory path components. Maybe we should
keep it that way; they are already consistent with the standard definition.
If we are to add definitions, a reduced and simplified set of the boost.org
definitions might be a good basis. Here is a slight reduction of their own
definitions:
* file: An object that can be written to, or read from, or both.
* filename: The name of a file.
* file system: A collection of files and certain of their
attributes.
* path: A sequence of elements that identify the location of a file
within a filesystem. The elements are the root-nameopt, root-directoryopt,
and an optional sequence of filenames.
* absolute path: A path that unambiguously identifies the location
of a file without reference to an additional starting location.
* relative path: A path that is not absolute, and so only
unambiguously identifies the location of a file when resolved relative to an
implied starting location.
* pathname: A character string that represents the name of a path.
Some notes:
1. They use “filename” and “pathname” with no spaces. Not sure how much
that
matters.
2. They use the term “absolute path”, which is what DLL_Path uses.
3. We might not need to define “file system”.
4. These definitions are for programming, which is why they define
“filename” and “pathname” independently of “file” and “path”. We could
reduce this.
5. Their definitions did not include “stem” and “extension”, although
these
are described in the methods.
Considering all of the above we might have something like these simplified
definitions:
* file name: The name of a file without its location.
* stem: The portion of a file name before the last dot, or the full file
name if no dot.
* extension: The portion of a file name after the last dot, if any.
* path: A sequence of directory elements and file name that identify the
location of a file.
* absolute path: A path that unambiguously identifies the location of a
file
without reference to an additional starting location.
* relative path: A path that is not absolute, and so only unambiguously
identifies the location of a file when resolved relative to an implied
starting location.
Those definitions should be sufficient to handle all of the places where we
state character rules about file names. In most places, the term “file name”
would not need to change. They should also be sufficient for the places
where we describe what types of file references are allowed.
Mike
From: ibis-editorial-bounce@xxxxxxxxxxxxx
[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Bob Ross
Sent: Monday, April 24, 2017 12:57 PM
To: michael.mirmak@xxxxxxxxx; 'Muranyi, Arpad' <Arpad_Muranyi@xxxxxxxxxx>;
mlabonte@xxxxxxxxxx
Cc: ibis-editorial@xxxxxxxxxxxxx; 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
Subject: [ibis-editorial] Re: File name concepts as used in IBIS 6.1
All,
Good information.
Do other specifications or languages have these definitions or similar
definitions?
Also, we allow a Filename to have a Stem only. Eg., S4p by itself is
legal.
Also we define extension as the text following the last “.”, and not
including the “.”. However, we have been inconsistent here from IBIS V2.0
or below.
Bob
From: <mailto:ibis-editorial-bounce@xxxxxxxxxxxxx>
ibis-editorial-bounce@xxxxxxxxxxxxx [
<mailto:ibis-editorial-bounce@xxxxxxxxxxxxx>
mailto:ibis-editorial-bounce@xxxxxxxxxxxxx] On Behalf Of Mirmak, Michael
Sent: Monday, April 24, 2017 9:37 AM
To: Muranyi, Arpad; <mailto:mlabonte@xxxxxxxxxx> mlabonte@xxxxxxxxxx
Cc: <mailto:ibis-editorial@xxxxxxxxxxxxx> ibis-editorial@xxxxxxxxxxxxx;
IBIS-ATM ( <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx)
Subject: [ibis-editorial] Re: File name concepts as used in IBIS 6.1
Mike, thanks for the Python analysis; Arpad, thanks for the links!
The online discussion mentioned the “boost.org” system, which is being
applied specifically to C++. While we should also consider VHDL and Verilog
(and variants), as IBIS supports them, IBIS-AMI with C++ is used fairly
often, so using a C++-friendly approach makes sense.
From the Boost naming convention
(http://www.boost.org/doc/libs/1_64_0/libs/filesystem/doc/reference.html#path-decomposition)
and the stackoverflow discussion:
Part Windows Posix
------------------------------------------------
Root name c: <empty>
Root directory \ /
Root path c:\ /
Relative path foo\bar\baa.txt foo/bar/baa.txt
Parent path c:\foo\bar /foo/bar
Filename baa.txt baa.txt
Stem baa baa
Extension .txt .txt
Path c:\foo\bar\baa.txt /foo/bar/baa/txt
In this nomenclature, our “basename” becomes “stem”, “file extension”
becomes “extension”, and “file name” and variants become “filename”.
Relatively few changes would be required in the existing IBIS text, but an
introductory paragraph would be needed to explain the notation above and
provide suitable references. We could also easily note that other languages
and systems (making explicit note of Python as an example) may assign the
same terms to different concepts.
Will this work?
- MM
From: Muranyi, Arpad [mailto:Arpad_Muranyi@xxxxxxxxxx]
Sent: Monday, April 24, 2017 9:16 AM
To: mlabonte@xxxxxxxxxx <mailto:mlabonte@xxxxxxxxxx> ; Mirmak, Michael
<michael.mirmak@xxxxxxxxx <mailto:michael.mirmak@xxxxxxxxx> >
Cc: ibis-editorial@xxxxxxxxxxxxx <mailto:ibis-editorial@xxxxxxxxxxxxx> ;
IBIS-ATM (ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> )
<ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >
Subject: RE: File name concepts as used in IBIS 6.1
Just to add another twist to this conversation, in the HTML world, they
call this a URL. A URL can practically be anything, but in the end, it
is a reference to a file, whether it is local or somewhere in the big
wide world. Look at what they call the various components of a URL here:
<https://www.w3schools.com/html/html_urlencode.asp>
https://www.w3schools.com/html/html_urlencode.asp
Can we learn something from this?
By the way, we don’t seem to be the only ones wrestling with this:
<http://stackoverflow.com/questions/2235173/file-name-path-name-base-name-naming-standard-for-pieces-of-a-path>http://stackoverflow.com/questions/2235173/file-name-path-name-base-name-naming-standard-for-pieces-of-a-pathThanks,Arpad==========================================================================From:
ibis-editorial-bounce@xxxxxxxxxxxxx<mailto:ibis-editorial-bounce@xxxxxxxxxxxxx>[mailto:ibis-editorial-bounce@xxxxxxxxxxxxx]
On Behalf Of Mike LaBonteSent: Friday, April 21, 2017 8:33 PMTo: Michael
Mirmak <michael.mirmak@xxxxxxxxx<mailto:michael.mirmak@xxxxxxxxx> >Cc:
ibis-editorial@xxxxxxxxxxxxx <mailto:ibis-editorial@xxxxxxxxxxxxx> ;IBIS-ATM
(ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx>
)<ibis-macro@xxxxxxxxxxxxx <mailto:ibis-macro@xxxxxxxxxxxxx> >Subject:
[ibis-editorial] Re: File name concepts as used in IBIS 6.1Looking outside of
IBIS for a moment, the Perl<http://perldoc.perl.org/File/Basename.html>
File::Basename functions are: ($name,$path,$suffix) =
fileparse($fullname,@suffixlist); $basename =
basename($fullname,@suffixlist); $dirname = dirname($fullname);In their
terminology, if $fullname = 'a/b/c.d' and @suffixlist = ('.d')then:$name =
c$path = a/b/$suffix = .d$basename = c.d$dirname = a/bSo their idea of basename
is what we in some places call file name. Notethat the use of DLL_ID as a
basename is a slightly different concept. IfDLL_ID is serdes_16544 then a DLL
might write files serdes_16544_cdrout.csvand serdes_16544_dfeout.csv. I wonder
if the term "file name fragment" mightwork better there?I think we need to
decide what we will call each entity:a/b/c.d file path? (not distinguishing
between full and relative paths)a/b directory path?c.d file name?c
file base name?d file extension?Michael's effort to find the
dominant current practice to determine aminimal change that results in a
consistent policy is worthwhile. Mysuggestions above would not necessarily
minimize the change. But Michaelseems to have found that "file name" is
currently used for both "c.d" and"c", so it seems to me some changes are
warranted somewhere in the spec, nomatter what we choose.Mike _____From:
"Michael Mirmak" <
<mailto:michael.mirmak@xxxxxxxxx>michael.mirmak@xxxxxxxxx>To: "
<mailto:ibis-editorial@xxxxxxxxxxxxx> ibis-editorial@xxxxxxxxxxxxx"
<<mailto:ibis-editorial@xxxxxxxxxxxxx> ibis-editorial@xxxxxxxxxxxxx>,"IBIS-ATM
( <mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx)"
<<mailto:ibis-macro@xxxxxxxxxxxxx> ibis-macro@xxxxxxxxxxxxx>Sent: Friday, April
21, 2017 7:19:15 PMSubject: [ibis-editorial] File name concepts as used in IBIS
6.1Today’s discussion of BIRD189.2 focused on the concept of “file name”
(andvariants on the term), and whether it refers to a string that includes
anextension, whether it is simply the pre-extension string, or whether
itincludes path information. As noted by Bob Ross, the BIRD189.2 language
isclosely 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 whereappropriate. All page
numbers refer to the Adobe PDF* version of the file.In brief, I believe Bob and
Arpad were correct in their statements duringthe meeting, and that there is a
long-standing inconsistency in how we referto files in even pre-3.2 IBIS. In
particular, the usage on pages 9 conflictwith 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
completelyconsistent by using the phrase “base name” for the non-extension
portion ofthe string, and “file name” for the full string, appropriately
anddistinctly defined, without forcing model or tool changes. Current
BIRDscould be made consistent with these definitions very easily.Comments are
welcome.- MMbasename--------p. 9 – In the “GENERAL SYNTAX RULES AND
GUIDELINES” section, “basename” maybe up to 40 characters in length, followed
by a period and anup-to-three-character extensionbase name--------p. 213 - "The
algorithmic model is responsible for using DLL_ID as the basename for any data
files that the model creates..."filename--------p. 140 - regarding .pkg,
“filename” refers to base file name withoutextensionp. 154 - regarding .ebd,
“filename” refers to base file name withoutextensionfile name--------p. 9 –
“basename” is 40 characters, followed by a period and anup-to-three-character
"file name extension" (so here, file name isequivalent 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 timesp. 120ff - for [External Circuit], “file name”
implies extension isincluded, but the phrase "file name extension" is used
several timesp. 221 - for Supporting_Files, "file name" is explicitly described
incontrast to directory names and paths
