ASTM G135-95(2001)
(Guide)Standard Guide for Computerized Exchange of Corrosion Data for Metals
Standard Guide for Computerized Exchange of Corrosion Data for Metals
SCOPE
1.1 This guide defines the techniques used to encode corrosion of metals test results for exchange between computer systems.
1.2 Guidelines are given for creating a data exchange appendix for each ASTM corrosion of metals standard.
1.3 Instructions are given for creating data translation software from the contents of the data exchange appendix.
General Information
Relations
Standards Content (Sample)
NOTICE: This standard has either been superseded and replaced by a new version or withdrawn.
Contact ASTM International (www.astm.org) for the latest information
Designation: G 135 – 95 (Reapproved 2001)
Standard Guide for
Computerized Exchange of Corrosion Data for Metals
This standard is issued under the fixed designation G 135; the number immediately following the designation indicates the year of
original adoption or, in the case of revision, the year of last revision. A number in parentheses indicates the year of last reapproval. A
superscript epsilon (e) indicates an editorial change since the last revision or reapproval.
1. Scope 4. Significance and Use
1.1 This guide defines the techniques used to encode corro- 4.1 This guide establishes a formalism for transferring
sion of metals test results for exchange between computer corrosion test data between computer systems in different
systems. laboratories. It will be used by standards developers to specify
1.2 Guidelines are given for creating a data exchange the format of files containing test results.
appendix for each ASTM corrosion of metals standard. 4.2 Thisguidedefinesagenericapproachtostructuringdata
1.3 Instructions are given for creating data translation soft- files. It will be used by software developers to create programs
ware from the contents of the data exchange appendix. which read and write these files.
4.3 Each standard test procedure will define a unique data
2. Referenced Documents
file derived from this guide. Each time a standard test is
2.1 ASTM Standards:
performed, the results can be summarized in a data file specific
G 106 Practice forVerification ofAlgorithm and Equipment to that test.
for Electrochemical Impedance Measurements
4.4 Some experimental information will be global, that is,
G 107 Guide for Formats for Collection and Compilation of common to several standards, and will be contained in Guide
Corrosion Data for Metals for Computerized Database
G 107 and other global data dictionaries. Other information
Input will be local, that is, unique to a given standard, and will be
2.2 ANSI Standards:
defined in that standard.
ANSI/ISO 9899: 1990 [1992] Programming Language C
5. Guide for Standards Authors
ANSI X3.4-1986: Coded Character Set 7 Bit ASCII
5.1 Local and Global Data:
3. Terminology
5.1.1 Some information may be used across several corro-
3.1 Definitions: sion standards, that is, global. Global data is defined in Guide
3.1.1 datatype—a group of rules specifying the format of an
G 107 and other global standards.
object. 5.1.2 Some information may be local to a particular corro-
3.1.2 global data—information shared among several stan-
sion standard. Local data is defined in the standard’s data
dards. exchange appendix.
3.1.3 local data—information specific to a certain standard.
5.2 Data File:
3.1.4 semantics—information meaning. 5.2.1 Eachtestwillgenerateasingletestdatafile.Filename
3.1.5 syntax—information format.
formats are not specified.
3.1.6 tagged object—a named block of information. 5.2.2 The data file is arranged as a set of named or tagged
3.1.7 translator—a computer routine which writes or reads
objects. Each time a standard test is performed a set of objects
data files. is obtained. The data file can be thought of as a permanent
repository for this set of objects.
5.2.3 Each tagged object will take two or more lines in the
This guide is under the jurisdiction ofASTM Committee G01 on Corrosion of
data file. Lines are strings of ASCII (ANSI X3.4-1986)
Metals and is the direct responsibility of Subcommittee G01.05 on Laboratory
characters terminated with a carriage return/linefeed character
Corrosion Tests.
Current edition approved Oct. 10, 1995. Published December 1995. pair or a single linefeed character.
Annual Book of ASTM Standards, Vol 03.02.
Available from American National Standards Institute, 11 W. 42nd St., 13th
Floor, New York, NY 10036.
Copyright © ASTM International, 100 Barr Harbor Drive, PO Box C700, West Conshohocken, PA 19428-2959, United States.
G 135 – 95 (2001)
5.2.4 Lines are further subdivided into tab delimited ASCII
fields that are particularly suitable for manipulation by spread-
sheet and scientific charting programs. For example, Fig. 1
shows how a section of a data file would show up on printed
output.
FIG. 2 The Elements of a Tagged Object
5.3 Tagged Object:
5.3.1 Atagged object is a repository for an individual block
(a) String (STRING)—Strings contain purely character
of information. It may be a simple piece of data, the test date
information. Strings may be further encoded depending on the
for example, or it may be complex, such as a current/voltage/
semantic description of the object.
time curve. A tagged object contains three subordinate areas:
(b) Quantity (QUANT)—Quantities represent numeric val-
(1)thetag,(2)thedatatype,and(3)theactualdata.Thetagand
ues along with their units. Units may be further encoded
datatype are the first two fields of the first line while the actual
depending on the semantic description of the object.
data is contained in subsequent lines. Data lines are always
(c) Date (DATE)—Dates are simple day specifiers.
indented one tab space. This is illustrated in Fig. 2.
(d) Time (TIME)—Times are simple time of day specifiers.
5.3.2 Tag:
(e) Category Set (SET)—Category sets are used to repre-
5.3.2.1 The object’s tag is a simple string that uniquely
sent choices. The actual meaning of each value is given in the
identifies it among other objects in a tagged object set.
semantic description of the object.
5.3.2.2 When implementing a translator for a given stan-
(f) Tabular (TABLE)—Tables are used to hold arrays of
dard, the implementation is free to define other tagged object
records. The datatype, units, and name of each column is also
names so long as they don’t clash with those defined in the
encoded.
standard. It is suggested that additional names be prefixed with
5.3.3.3 Aparticularimplementationofatestisfreetodefine
some unlikely and unique combination of alphanumeric char-
local datatypes as long as they don’t clash with those defined
acters so that name conflicts do not arise in future versions of
in global standards. These local datatypes are defined in the
the standard. For example; NewTest_Apex Potential.
standard’s data exchange appendix.
5.3.2.3 Tags are made up of one or more character strings
5.3.3.4 The datatype has a unique identifier made up of a
separated by periods. The first character in each string must be
standard number and a name separated by a period; for
alphabetic (including the underscore). Subsequent characters
example, G107.SET. Each time an object is recorded in the
may be alphanumeric.
data file, the datatype identifier is recorded with the object.
5.3.2.4 Periods should only be used to associate different
That identifier specifies to the translator (either computer or
objects together. For example, Matl.Class, Matl.SubClass,
human) what data format to use in reading the data from or
Matl.TradeName, are all aspects of Material. In future speci-
writing the data to the file.
fications it is suggested that this be done using complex,
5.3.3.5 In cases where the reading translator is unable to
multifield datatypes.
find a datatype in its internal table, that object will be marked
5.3.2.5 Periodsshouldnotbeusedtoseparatemultipleword
as untranslated. The translator is free to take the appropriate
individual concepts. Instead use capitalization or underscore.
action depending on the importance of the object.
For example; ControlMode or Control_Mode.
5.3.3.6 It is important to note that the datatype doesn’t
5.3.2.6 Tags are case insensitive although mixed case is
completelyspecifythemeaningofthedata,onlyitsformat.For
suggested for readability.
example, a value of one for the tag “Surface.Condition” has a
5.3.3 Datatype:
very different meaning than the value of one for the tag
5.3.3.1 Each object has a datatype which specifies the
“Potentiostat.ControlMode” even though they are both of type
format of the object’s data.
G107.SET. Those meanings are construed from the tag.
5.3.4 Data:
5.3.3.2 Global datatypes are defined in a global data ex-
change standard such as Guide G 107 and are repeated here for 5.3.4.1 The object’s data is arranged in a format defined by
reference, as follows: the datatype. Data starts in the second line of the data object.
FIG. 1 Data File Sample
G 135 – 95 (2001)
The data types may be global types defined in Guide G 107, or they may
There may be multiple lines and multiple fields associated with
be local to the standard being written.
a data object. Each data line is indented by one tab space to
(f) Category Set/Units/Column Information (Column 6)—This column
distinguish it from the tag/datatype lines.
varies depending on the datatype. If the type is a SET, Column 6 contains
5.4 Data Exchange Appendix:
the allowed values and meanings. If the type is a QUANT, Column 6
5.4.1 Standard tests that use this guide will contain a data
contains suggested units. If the type is a TABLE, Column 6 contains units
exchange appendix. This appendix contains the data and
or allowed values as required by the datatype of each column.
format information required to define test data files. For an
5.4.4 The last required section of the data exchange appen-
example see Appendix X1.
dix is a sample data file. This should show a file as actually
5.4.1.1 Thedataexchangeappendixshouldhavethreeparts,
printed although data may be omitted for the sake of space.
the local datatype definitions section, the object definition
table, and a sample data file.
6. Guide for File Translator Programmers
5.4.2 The local datatype definitions section gives a descrip-
tionofandformalsyntaxforeachlocaldatatype.Thisgivesthe
6.1 The following section is intended for programmers who
rulesoftranslationtoprogrammerswhoarecreatingtranslators
are writing data exchange translators. A translator is a portion
for the standard.
of a program which reads or writes a data file. Production rules
5.4.2.1 The rules should be written using the formal lan-
are shown in bold-face Courier font.
guage described in Section 7. The translation rules for several
6.1.1 Character Set—ThedataisstoredinanASCIItextfile
data types are given in Section 6. The QUANT type is
which can be directly printed using most printers and manipu-
reproduced in Fig. 3 as an example:
lated using most text editors (see Fig. 4).
5.4.3 The object definition table is a tabular listing of all the
6.1.2 File—Thedatafileisarrangedasasequenceoftagged
objects in the file. For example, consider Table 1. There are
objects.
four objects in this table: Standard, Date, ControlMode, and
File : = TaggedObject [1 . .*]
Spectrum. In an actual standard there may be many more.
6.1.3 Tagged Object—Ataggedobjectstartswithitstagline
5.4.3.1 Each row of the table defines a data object. These
and includes all the information up to the next tag. Any other
objects may be copied from global standards such as Guide
lines associated with the object must be indented one tab
G 107 or may be locally defined. An object definition should
character. Each line is terminated with a line feed or carriage
not refer to another standard test since a revision of that test
return/line feed pair.
may change the object definition without warning.
TaggedObject : = TagLine DataBlock
5.4.3.2 Column Definitions (as illustrated in Table 1):
6.1.3.1 Tag Line—The first line of a tagged object is called
NOTE 1—Columns 1, 2, and 3 are required for global objects. Columns
1 to 6 are required for local objects. the Tag Line. It contains the tag or name of the object and the
(a) Reference Number (Column 1)—The reference number is a unique
format specifier.
number referring back to the standard and paragraph where the data object
TagLine : = TagField FormatField {CommentField} NewLine
is defined. This number is made up of a Standard ID and a paragraph
number separated by a period(.). 6.1.3.2 Tag—A tag must start with an alphabetic character
(b) Tag/Column Tag (Column 2)—This column contains the data tag. If
or underscore ( ). Thereafter numeric characters can be used
the data object is tabular, this column will also contain sub-tags or
as well as alphabetic and underscore. Tags may not contain
headings for each column of the object.
spaces. The only other punctuation allowed is a period (.)
(c) Required (Column 3)—This column indicates whether a particular
character.Any character following a period must be alphabetic
object is required or can be safely omitted from the data file.
or underscore. Tags are not case sensitive.
(d) Description (Column 4)—The description column contains free
form text describing the object. Constraints, defaults, or other specifica- TagField : = Tag Tab
Tag : = Identifier (Period Identifier) [0 . .*]
tions may show up here.
Identifier : = AlphabeticChar AlphanumericChar [0 . .*]
(e) Datatype (Column 5)—The type gives the datatype of the object.
FIG. 3 Translation Rules for the Quant Data Object
G 135 – 95 (2001)
TABLE 1 Object Definitions
Reference Number/ Category Set/Suggested Units/
Tag/Column Tag Required Description/Column Description Type/Column Type
Column Number Column Information
G 107.5.1.4.1 Standard Yes Standard test specification STRING
G 107.5.1.4.3 Date Yes date test started DATE
G 106.X2.1 ControlMode Yes Circuit configuration SET Allowed Values
1. Potentiostat
2. Galvanostat
3. ZRA
4. V applied/No feedback
5. I applied/No feedback
6. Other
G 106.X2.2 Spectrum Yes Corrected frequency spectrum TABLE
Column 1 Frequency Frequency QUANT Hz
Column 2 Signal Applied Signal QUANT V, A
Column 3 ZReal Z real QUANT ohm
Column 4 ZImag Z imaginary QUANT ohm
Column 5 StdDev Standard Deviation QUANT none
FIG. 4 Definition of the Character Set
6.1.3.3 Format—The second field in the Tag Line is a object.Aspreviouslystated,datalinesmustbeginwithatabso
format specifier, either by paragraph reference; for example,
that they may be distinguished from tag lines. The data lines
Guide G 107.7.1.4.1, or by shorthand name; for example,
are subdivided into tab delimited fields, that is, each data field
STRING. The format specifier specifies how the rest of the
is followed by a tab.
tagged object is to be translated.
DataBlock : = DataLine [0 . .*]
DataLine : = Tab DataField [0 . .*] {CommentField} NewLine
FormatField : = {Organization Period} Standard Period Identifier Tab
6.1.3.4 Data Lines—Any lines following the tag line up to
the next tag line are data lines associated with the tagged
G 135 – 95 (2001)
6.1.3.5 Data Fields—Data fields may not start with semi-
colons.Datafieldsmustcontainonlyprintablecharacters.Data
6.1.5.4 Time (TIME)—A time is a string of six numeric
fields must not contain any internal tab characters since a tab
characters encoding hour, minute, and second in the order
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.