DLIS-RP66-PART-6

lzn_sc

Part 6: Basic Schema
Edition 1
1 - ScopeUsing the methodology outlined in Part 1, this part describes the schema, namely the collection of object types, administered by the Subcommittee On Recommended Format For Digital Well Data using organization code 0 (zero). This schema described in this part is called the basic schema. It includes object types required by any implementation of RP66, namely FILE-HEADER and ORIGIN, and object types for recording data of a general nature, for example FRAME and CHANNEL. The object types of the basic schema are intended to be industry-neutral. Some attributes of the basic schema object types have values restricted to a dictionary of standard reference values. These are listed in Part 7.
2 -
Definitions
3 - AuthorityChanges to the basic schema are recommended by the Subcommittee On Recommended Format For Digital Well Data and approved by POSC. Changes may include addition of new object types, addition of new attributes to existing object types, changes to the restrictions on existing attributes, or removal of attributes or object types. An attribute or object type removed in one edition may be restored in a later edition only if restored with its previous meaning. A new edition of the basic schema occurs when approved by POSC, and has an edition number obtained by adding 1 to the previous edition number. The intent is to maintain as much consistency as possible between editions. The principle motivation for a new edition should be to add new object types or attributes. However, from time to time compelling reasons arise for removing items because they are unused or impose unreasonable burdens on users and implementations.
4 - ConceptsA schema is a collection of object types specified and administered by an organization (see Part 1). The schema is identified by an organization code (see Appendix A). The object types support writing data of interest to the organization and reflect a data model adopted by the organization, whether explicitly or implied.
The data model represented by the basic schema is implied by the descriptions of the object types given in this part. The basic schema provides two kinds of object type:

• Object types required in every RP66 implementation to delimit logical files and establish the context of data included in logical files. These include
  
  
  
  • FILE-HEADER, used to delimit the beginning of a logical file.
    
  • ORIGIN, used to identify and distinguish logical files and establish the context used to interpret other objects.
  
  
• Object types intended to be industry-neutral that support recording data of a general nature. These include
  
  
  
  • AXIS, used to describe a single coordinate axis of an array.
    
  • CHANNEL, used to describe the meaning and representation of an indexed sequence of data values called a (data) channel.
    
  • COMMENT, used to write a textual comment.
    
  • COMPUTATION, used to describe the source and result of a computation derived from other data.
    
  • FRAME, used to describe the organization of several commonly-indexed channels into a sequence of IFLRs called frame blocks, where each frame block consists of one or more frames, and each frame has one value from each channel.
    
  • GROUP, used to describe application-defined groupings of other objects.
    
  • NO-FORMAT, used to identify IFLRs that contain unformatted data, i.e., for which no format description is provided other than a name.
    
  • ORIGIN-TRANSLATION, used to maintain an origin translation table for encrypted logical records.
    
  • PARAMETER, used to write parametric data.
    
  • PROCESS, used to describe a process by which other data was acquired or computed, including declarations of input data, output data, and parameters.
    
  • UPDATE, used to indicate a change in the value of an attribute previously written in the same logical file.
    
  • ZONE, used to identify an interval over which a value is defined or valid.
    5 - Unit ModelThe basic schema does not impose any unit restrictions other than `u=' (unitless), when applicable. Unless declared unitless, an attribute may have any unit from any unit model having a valid unit model code and name.
    6 - Dictionary-Controlled IdentifiersThe following object types are required to have dictionary-controlled identifiers (see Part 2):
    
    
    
    • CHANNEL
      
    • COMPUTATION
      
    • PARAMETER
      
    • PROCESS
    
    7 - Required vs Optional Use Of AttributesUse of any attribute is considered optional unless otherwise stated. More stringent requirements on presence of attributes is delegated to content standards, which are not part of this document.
    8 - Frequently-Used AttributesThe attributes listed in Table\x111 may appear in many object types and have the same or similar meaning in each place used. The similarities are described once here and not repeated. Extended uses and whether use is mandatory or optional may be described under the various object types that have these attributes.
    Table 1 - Frequently-Used Attributes
    *Note
    Attribute Label
    Restrictions
    1
    
    AGGREGATE
    r=ULONG, u=
    2
    
    AXIS
    r=OBNAME, u=
    3
    
    DESCRIPTION
    c=1, r=ASCII, u=
    4
    
    DIMENSION
    r=ULONG, u=
    5
    
    EXTENDED-ATTRIBUTES
    r=OBJREF, u=
    6
    
    PROPERTIES
    r=IDENT | TIDENT, u=, v=(see note) *Notes:
    
    
    
    • 1 AGGREGATE is a vector of integers that describe the structure of a value interpreted to be a set of nested 1-dimensional arrays of differing lengths. The particular value typically, though not always, belongs to one or more other attributes in the same object, and is identified as part of the description of the object type. The first element of AGGREGATE is the number n1 of first level aggregations. The next n1 elements contain the numbers of level 2 aggregations, and so on. The last set of elements contain the sizes of the nested 1-dimensional arrays. Examples are provided in Figure\x111. DIMENSION and AGGREGATE are mutually exclusive. If one is present, the other must be absent.
      
    • 2 AXIS is a list of references to AXIS objects (see 10.1). A referenced AXIS object describes one coordinate axis of an array. The AXIS attribute must be used in conjunction with a DIMENSION attribute. Whereas a DIMENSION element describes the extent of a coordinate axis (number of coordinate values), the corresponding referenced AXIS object further describes a starting coordinate, spacing between coordinates, coordinate axis units, specific coordinate values, etc.
      
    • 3 DESCRIPTION is a human-readable, textual description of the object and is not intended to impose or posess syntactic or semantic content. It is available in all basic schema object types except FILE-HEADER and has the same usage everywhere.
      
    • 4 DIMENSION is a vector of integers that specify the dimensions of a bounded array. The particular array is often, though not always, the value of one or more other attributes in the same object, and is identified in the description of the object type. The common interpretation of a bounded array structure as described by a DIMENSION attribute is given in 8.1. This interpretation may be extended for specific object types that use DIMENSION. One kind of extension, addition of an unbounded dimension, is discussed in the description of the FRAME object type. DIMENSION and AGGREGATE are mutually exclusive. If one is present, the other must be absent.
      
    • 5 EXTENDED-ATTRIBUTES is a list of references to other objects, typically in other schemas, that contain additional privately-defined attributes that apply to the given object. It is available in all basic schema objects except FILE-HEADER and ORIGIN and has the same meaning everywhere.
      
    • 6 PROPERTIES is a list of dictionary-controlled reference values that indicate the general intrinsic nature of the data associated with an object and the general processing steps that have been performed to create it. Properties are not mutually exclusive and may be associated in various combinations with the data of a particular object. Properties are intended to provide broad classifications for objects. There are currently no reference values defined under the basic schema.
    
    file:///C:/Documents%20and%20Settings/Administrator/桌面/RP66V2_20030702/rp66v2_sec6_fig1a.gif
    
    file:///C:/Documents%20and%20Settings/Administrator/桌面/RP66V2_20030702/rp66v2_sec6_fig1b.gif
    Figure 1 - Examples of Aggregates
    8.1 - Interpretation of a Dimensioned ArrayDIMENSION count specifies the dimensionality of a bounded array, i.e., its number of independent, bounded coordinate axes. Each DIMENSION element specifies the extent of one coordinate axis. For example, DIMENSION = {3, 4, 128} describes a 3 by 4 by 128 array. If DIMENSION count > 0, the total number of elements of the bounded array is the product of the DIMENSION elements. The example array has 3x4x128 = 1,536 elements. DIMENSION count shall be greater than zero (0) unless specifically allowed in special cases described for individual object types.
    An array is written as a linear sequence of elements. The mapping of this sequence to the structure defined by DIMENSION is such that the first coordinate index changes most rapidly, and the last coordinate index changes most slowly. If the elements of the array are denoted by Ai,j,k, then the linear order of elements is A1,1,1, A2,1,1, A3,1,1, A1,2,1, A2,2,1, ..., A3,4,1, A1,1,2, A2,1,2, ..., A3,4,128.
    9 - Required Object Types
    9.1 - FILE-HEADERA single FILE-HEADER object delimits the beginning of a logical file and serves as its identifying label. Every logical file shall have exactly one FILE-HEADER object. This is required of all schemas. Furthermore, no schema other than this basic schema may define an object type called FILE-HEADER.
    Unless the END-OF-STORAGE-SET attribute is present and true (value = 1), the origin subfield of the FILE-HEADER name must reference the logical file's first ORIGIN object (see 9.2).
    
  
  Table 2 - FILE-HEADER Attributes
  *Note
  Attribute Label
  Restrictions
  1
  
  SEQUENCE-NUMBER
  c=1, r=ULONG, u=
  2
  
  ID
  c=1, r=ASCII, u=
  3
  
  END-OF-STORAGE-SET
  c=1, r=STATUS, u=
  4
  
  CONTENT-STANDARD-CODE
  r=ULONG, u=
  5
  
  CONTENT-STANDARD
  r=IDENT, u=
  6
  
  CONTENT-STANDARD-EDITION
  r=IDENT, u= *Notes:
  
  
  
  • 1 SEQUENCE-NUMBER is a positive integer that indicates the relative sequential position of the logical file in its storage set. It must be greater than SEQUENCE-NUMBER of the previous logical file in the same storage set and may be any positive integer for the first logical file. This attribute is required.
    
  • 2 ID is a descriptive identification of the logical file.
    
  • 3 END-OF-STORAGE-SET is used to indicate the end of a storage set (see Part 3 for a description of storage sets.) When this attribute is present and true (value = 1), then the corresponding logical file shall have no records other than the EFLR containing the FILE-HEADER set, i.e., it is an empty logical file. A logical file may be empty only when this attribute is present and true, since all other logical files are required to have at least an ORIGIN set (see 9.1.2). Furthermore, no other logical files in the same storage set may follow an empty logical file, and every storage set is required to end with an empty logical file.
    
  • 4 CONTENT-STANDARD-CODE is a list of organization codes (see Appendix A) of the organization or organizations responsible for defining content standards to which the logical file adheres.
    
  • 5 CONTENT-STANDARD is a list of of a content standard names corresponding in order to the elements of CONTENT-STANDARD-CODE. Each name identifies a standard for arrangement and/or quality to which the logical file contents are assumed to adhere.
    
  • 6 CONTENT-STANDARD-EDITION is a list of editions of content standards corresponding in order to the elements of CONTENT-STANDARD.
  Several of the constraints on FILE-HEADER that were present in RP66 V1 have been dropped in this edition, notably the fixed-field-size and rigid organization constraints. These constraints did not accomplish the goal of supporting general file management utilities. Note that if a logical file is copied to another storage set its SEQUENCE-NUMBER may have to change to satisfy the sequential position requirement for the new storage set.
  9.2 - ORIGINORIGIN objects contain information used to identify and distinguish logical files and establish the context for interpreting and distinguishing other objects. Every logical file shall have at least one ORIGIN object that immediately follows the FILE-HEADER and may have additional ORIGIN objects as required, not necessarily contiguous with the first. The first ORIGIN object in a logical file is called the defining origin.
  Attributes FILE-ID, FILE-SET-NAME, FILE-SET-NUMBER, FILE-NUMBER, FILE-TYPE, and CREATION-TIME are used for logical file identification. With high probability (based on the effectiveness of random number generators), it should suffice to use only FILE-SET-NUMBER and FILE-NUMBER from the defining origins to distinguish two logical files having different content.
  Every object in a logical file shall have an origin subfield in its object name that matches exactly one ORIGIN object in the same logical file. Except for FILE-HEADER and ORIGIN, any object must follow the ORIGIN object it references. This rule implies that all ORIGIN objects in the same logical file must have distinct origin subfield values.
  An object may originate in the logical file in which it is contained, or it may represent a copy of part or all of an object that originated in another logical file. The logical file in which an object originates is called its parent file. The parent file of the defining origin is the file in which it is contained. Other ORIGIN objects may have different parent files. The parent file of an ORIGIN object is the one for which the attributes FILE-ID, FILE-SET-NAME, FILE-SET-NUMBER, FILE-NUMBER, FILE-TYPE, and CREATION-TIME match those of the defining origin. The parent file for any other object is the same as for the ORIGIN object it references.
  When objects are copied, some origin subfield values may have to change to preserve the distinctness rule stated in 9.2.3. Thus, origin subfield values need not be preserved by copy operations. The process of changing origin subfield values during copy or merge operations is called origin translation. The primary rule is referential consistency. Whenever a copied ORIGIN object requires origin translation, then all other objects that reference it in the source logical file must, if copied, have the same origin translation applied. Furthermore, any attributes that have origin values (e.g., OBNAME) must also be translated. The following strategies can help reduce the need for origin translation: First, unless unavoidable write all ORIGIN objects immediately after the FILE-HEADER. This helps edit applications, which must create a new defining origin for the edited output, to select an origin value distinct from the source origin values. An edit application, of course, must be prepared to encounter additional origins later in the file and handle possible origin translation if there is a conflict. However, if the source file has written all origins at the front, the need for translation will not arise. Second, generate origin values randomly to reduce the probability that two logical files being merged into a third will have duplicate origin values.
  No schema other than this basic schema may define an object type called ORIGIN.
  The rules in 9.2.1 through 9.2.6 are required of all schemas. Table 3 describes the attributes of ORIGIN objects.
  Table 3 - ORIGIN Attributes
  *Note
  Attribute Label
  Restrictions
  -
  DESCRIPTION
  c=1, r=ASCII, u=
  1
  
  FILE-ID
  c=1, r=ASCII, u=
  2
  
  FILE-SET-NAME
  c=1, r=IDENT, u=
  3
  
  FILE-SET-NUMBER
  c=1, r=ULONG, u=
  4
  
  FILE-NUMBER
  c=1, r=ULONG, u=
  5
  
  FILE-TYPE
  c=1, r=IDENT, u=
  6
  
  CREATION-TIME
  c=1, r=DTIME, u=
  7
  
  SCHEMA-CODE
  c=1, r=ULONG, u=
  8
  
  SCHEMA-ORGANIZATION
  c=1, r=ASCII, u=
  9
  
  SCHEMA-EDITION
  u=
  10
  
  SCHEMA-DICTIONARY-EDITION
  u=
  11
  
  UNIT-MODEL-CODE
  c=1, r=ULONG, u=
  12
  
  UNIT-MODEL-NAME
  c=1, r=IDENT, u=
  13
  
  UNIT-MODEL-EDITION
  u=
  14
  
  UNIT-SYMBOLS-EDITION
  u=
  15
  
  NAMESPACE-CODE
  c=1, r=ULONG, u=
  16
  
  NAMESPACE-NAME
  c=1, r=IDENT, u=
  17
  
  NAMESPACE-ORGANIZATION
  c=1, r=ASCII, u=
  18
  
  NAMESPACE-EDITION
  u=
  19
  
  REMARK
  c=1, r=ASCII, u=
  20
  
  CONTEXT
  c=1, r=OBJREF, u= *Notes:
  
  
  
  • 1 FILE-ID is an exact copy of the FILE-HEADER:ID attribute of the parent file. This attribute is required.
    
  • 2 FILE-SET-NAME is the name of a file set, a group of logical files to which the parent file belongs. The logical files in a file set are related according to implementation-defined criteria.
    
  • 3 FILE-SET-NUMBER is a random number used to identify a file set. This attribute is required.
    
  • 4 FILE-NUMBER identifies the parent file within a file set. It is a positive integer that represents the relative chronological order in which the logical file was created in the file set. The earliest logical file in a file set may have any positive file number. Any other logical file in the file set must have a file number that is greater than that of any earlier logical file in the same file set. Although file numbers are distinct in a file set, they are not required to be distinct in a storage set. This attribute is required.
    
  • 5 FILE-TYPE is an implementation-defined name that identifies the general contents of the parent file or the circumstances under which the parent file was created.
    
  • 6 CREATION-TIME is the date and time at which the parent file was created. This should be a time close to when the FILE-HEADER was written. This attribute is required.
    
  • 7 SCHEMA-CODE is the organization code (see Appendix A) of the organization responsible for defining the object types, other than FILE-HEADER and ORIGIN, having this origin. This attribute is required.
    
  • 8 SCHEMA-ORGANIZATION is the name of the organization assigned the code specified in SCHEMA-CODE.
    
  • 9 SCHEMA-EDITION is the edition of the document describing the schema or schema derivation methodology corresponding to SCHEMA-CODE.
    
  • 10 SCHEMA-DICTIONARY-EDITION is the edition of the dictionary of reference values used by attributes of the schema corresponding to SCHEMA-CODE.
    
  • 11 UNIT-MODEL-CODE is the organization code (see Appendix A) of the organization responsible for defining the unit model used by objects having this origin.
    
  • 12 UNIT-MODEL-NAME is the name of the unit model used by objects having this origin.
    
  • 13 UNIT-MODEL-EDITION is the edition of the document describing the unit model used by objects having this origin.
    
  • 14 UNIT-SYMBOLS-EDITION is the edition of the document describing the unit symbols used by objects having this origin.
    
  • 15 NAMESPACE-CODE is the organization code (see Appendix A) of the organization responsible for administering the dictionary of object names used by objects having this origin.
    
  • 16 NAMESPACE-NAME is the name of the dictionary of object names for objects having this origin.
    
  • 17 NAMESPACE-ORGANIZATION is the name of the organization assigned the code specified in NAMESPACE-CODE.
    
  • 18 NAMESPACE-EDITION specifies the edition of the dictionary in which dictionary-controlled object names are administered for this origin.
    
  • 19 REMARK is an optional remark applicable to objects having this origin.
    
  • 20 CONTEXT is a reference to an object defined under the schema specified in SCHEMA-CODE. The referenced object has attributes that establish additional context for interpreting the data having this origin. To allow multiple ORIGIN objects to share a context, the referenced object may have an origin different from this one so long as the corresponding schema code is the same.
  Since FILE-HEADER and ORIGIN are required in any implementation, most logical files will have a minimum of two ORIGIN objects, one for the basic schema, and one for the industry schema that covers the data of interest. In some cases the basic schema alone may suffice to exchange meaningful data. Declaration of required attributes is intentionally very selective. Whenever possible this decision is delegated to organizations that use RP66. Nevertheless, most non-required attributes should be viewed as important to making full sense of the data.
  10 - Optional Object Types
  10.1 - AXISAn AXIS object describes one coordinate axis of an array. AXIS objects shall be used in conjunction with a DIMENSION attribute (see 8). The extent of the array along the coordinate axis, i.e., number of coordinate values, is determined by a DIMENSION attribute. Additional information provided by the AXIS object includes explicit coordinate values, coordinate axis units, and spacing between computed coordinate values.
  When the array is a channel value (see 10.2), its coordinates may be modulated from frame to frame by reference to another channel value that provides dynamic coordinate values.
  For example, a seismic trace may be represented as a 1-dimensional array along a time coordinate and written as a channel value described by CHANNEL object TRACE. From trace to trace (frame to frame), the initial time coordinate of the trace may change, although the trace sample interval remains fixed, say at 4 ms. The initial time can be written as a companion channel in the same frame type, described by CHANNEL TRACE_START_TIME. A corresponding AXIS object may then specify SPACING = 4 ms and COORDINATES = TRACE_START_TIME.
  Table 4 - AXIS Attributes
  *Note
  Attribute Label
  Restrictions
  -
  DESCRIPTION
  c=1, r=ASCII, u=
  -
  EXTENDED-ATTRIBUTES
  r=OBJREF, u=
  1
  
  AXIS-ID
  c=1, r=IDENT, u=, v=(see note)
  2
  
  COORDINATES
  r=(see note)
  3
  
  SPACING
  c=1, r=(see note) *Notes:
  
  
  
  • 1 AXIS-ID is a dictionary-controlled reference value identifying the coordinate axis. Valid identifiers are administered in the dictionary specified by the NAMESPACE-CODE and NAMESPACE-NAME attributes of the object's origin. There are currently no reference values defined under the basic schema.
    
  • 2 COORDINATES specifies coordinate values along the axis, which may be either textual (for labels) or numeric. Compound representation codes are prohibited except for OBNAME. When r=OBNAME, then COORDINATES is the name of a single CHANNEL object whose value may be textual or numeric. COORDINATES may reference a CHANNEL object only if the described array is a channel value and both the array and referenced channel are in the same frame type. When the number of coordinate values specified by COORDINATES is less than the extent of the array as derived from the companion DIMENSION attribute, then subsequent coordinate values are computed in SPACING increments from the last coordinate value.
    
  • 3 SPACING specifies a constant, signed, spacing along the axis between successive coordinates, beginning at the last coordinate value specified by COORDINATES. If COORDINATES is absent, then regularly-spaced coordinate values are implied beginning at zero (0) and separated by the declared spacing. Textual and compound representation codes are prohibited except for OBNAME. When r=OBNAME, then SPACING is the name of a single CHANNEL object whose value shall be numeric and have only one element. SPACING may reference a CHANNEL object only if the described array is a channel value and both the array and referenced channel are in the same frame type.
  
  10.2 - CHANNELA CHANNEL object describes an instance of a channel. A channel is a named sequence of measured or computed values typically associated with an index such as depth or time. Channel values are recorded in frames (see 10.5). The CHANNEL object identifies the channel instance and specifies its representation in the frame. Channel values are similar to attribute values in that they consist of zero or more elements, all having the same units and representation code. The count, units, and representation code of a channel value are provided by its associated CHANNEL object.
  Table 5 - CHANNEL Attributes
  *Note
  Attribute Label
  Restrictions
  -
  DESCRIPTION
  c=1, r=ASCII, u=
  -
  EXTENDED-ATTRIBUTES
  r=OBJREF, u=
  1
  
  KIND
  c=1, r=ASCII | TASCII, u=, v=(see note)
  2
  
  PROPERTIES
  r=IDENT | TIDENT, u=, v=(see note)
  3
  
  FLAGS
  r=IDENT | TIDENT, u=, v=(see note)
  4
  
  REPRESENTATION-CODE
  c=1, r=USHORT, u=
  5
  
  FIXED-SIZE-IN-BYTES
  c=1, r=ULONG, u=
  6
  
  UNITS
  c=1, r=UNITS, u=
  7
  
  DIMENSION
  r=ULONG, u=
  8
  
  DIMENSION-LIMIT
  c=1, r=ULONG, u=
  9
  
  AGGREGATE
  r=ULONG, u=
  10
  
  AGGREGATE-LIMIT
  c=1, r=ULONG, u=
  11
  
  ELEMENT-LIMIT
  c=1, r=ULONG, u=
  12
  
  SOURCE
  c=1, r=OBJREF
  13
  
  AXIS
  r=OBNAME, u=
  14
  
  ABSENT-ELEMENT
  c=1
  15
  
  SPACING
  -
  16
  
  DIRECTION
  c=1, r=IDENT | TIDENT, u=, v=(see note)
  17
  
  MINIMUM-VALUE
  -
  18
  
  MAXIMUM-VALUE
  - *Notes:
  
  
  
  • 1 KIND is a dictionary-controlled reference value that describes a general classification of the channel. Finer differentiation of the channel is provided by its identifier. Currently there are no reference values defined under the basic schema.
    
  • 2 See Table\x111.
    
  • 3 FLAGS is a dictionary-controlled list of reference values that describe recording options for the channel. Reference values are listed in Part 7.
    
  • 4 REPRESENTATION-CODE is the representation code used to write each element of a channel value. This attribute is required.
    
  • 5 FIXED-SIZE-IN-BYTES declares a fixed number of bytes used to write each element of a channel value which has a variable-length representation code. This attribute may be used only if the representation code has an ASCII or IDENT subfield. When used, it is a guarantee that every element is written using the declared number of bytes. When the actual value of an element is shorter, one or more of the ASCII or IDENT subfields will be padded (using a null delimiter) to achieve the declared length.
    
  • 6 UNITS is the unit of each element of a channel value. The unit model is obtained from the channel object's origin. If absent, the value is considered to be unitless.
    
  • 7 DIMENSION describes the structure of a channel value (see Table\x111). When both DIMENSION and AGGREGATE are absent and the channel is not explicitly-sized (see Part 7), each channel value is assumed to have one element.
    
  • 8 DIMENSION-LIMIT declares the upper value of the dimension descriptor count of the channel when the channel is explicitly sized (see FLAGS). In any frame, count may either be zero, in which case the channel value is absent from the frame, or it may equal DIMENSION-LIMIT. A channel is not allowed to change dimensionality other than to become absent. DIMENSION and DIMENSION-LIMIT are mutually exclusive. If one is present, the other shall be absent.
    
  • 9 AGGREGATE describes the the structure of a channel value (see Table\x111). When both DIMENSION and AGGREGATE are absent and the channel is not explicitly-sized (see Part 7), each channel value is assumed to have one element.
    
  • 10 AGGREGATE-LIMIT declares a limit on the count of the aggregate descriptor of the channel when the channel is explicitly sized (see FLAGS). The count shall not exceed this limit and may or may not reach it. AGGREGATE and AGGREGATE-LIMIT are mutually exclusive. If one is present, the other shall be absent.
    
  • 11 ELEMENT-LIMIT is a limit on the total number of elements per value (i.e., per frame) of the channel when explicitly sized (see FLAGS). The number of elements per value shall not exceed this limit and may or may not reach it. This attribute shall be absent if the channel is not explicitly-sized.
    
  • 12 SOURCE is a reference to another object, for example a PROCESS object, that describes the immediate source of the channel.
    
  • 13 AXIS is a list of references to AXIS objects that describe the channel value (see Table\x111). When AXIS and DIMENSION are both present, they shall have the same count. That is, there shall be one AXIS object reference for each coordinate axis of the channel value. When AXIS is present and the channel is explicitly sized, then AXIS count shall equal the value of DIMENSION-LIMIT.
    
  • 14 ABSENT-ELEMENT has a single element which shall have the same units and representation code as the channel value. Any channel value element that matches this attribute is considered to be absent, i.e., not valid for use.
    
  • 15 SPACING declares a fixed signed spacing between channel values in successive frames for all frames of the frame type. It need not have the same units or representation code as the channel value. However, it shall have the same number of elements, and there shall be a units conversion s -> s' such that s' = v(n) - v(n - 1) for all frame numbers n > 1, where s is the value of SPACING and v(n) is the channel value in frame n. This attribute does not apply to explicitly-sized channels and shall not be present if the channel is explicitly-sized (see FLAGS). If the channel value has more than one element, then corresponding elements are uniformly spaced.
    
  • 16 DIRECTION is a dictionary-controlled reference value that provides qualitative information about the behavior of the channel value as a function of frame number. When the channel has more than one element, the behavior applies on an element-by-element basis. Reference values are listed in Part 7.
    
  • 17 MINIMUM-VALUE is the minimum channel value for all frames of the frame type. If the channel value has more than one element, it is an element-by-element minimum. That is, each element of this attribute is the minimum of the corresponding channel value element for all frames in the frame type.
    
  • 18 MAXIMUM-VALUE is the maximum channel value for all frames of the frame type. If the channel value has more than one element, it is an element-by-element maximum. That is, each element of this attribute is the maximum of the corresponding channel value element for all frames in the frame type.
  
  RP66 V1 had a FRAME:INDEX-TYPE attribute which applied only to the index channel and has been dropped in this edition. KIND provides the same feature for any channel, regardless of use as an index.
  The main usefulness of SPACING is to describe channels used as regular indexes, which have no need to change size. If it were to apply to explicitly-sized channels then it would need to be updatable, which would make for very cumbersome rules on how to maintain a constant spacing when spacing can change.
  In contrast to ABSENT-ELEMENT which is essentially always used internally (i.e. by the computer), SPACING is frequently of interest to the end user, and some latitude is given to allow it to be presented in a friendlier form than the channel value, namely to have different though compatible units and representation code.
  10.3 - COMMENTA COMMENT object carries arbitrary textual information considered interesting to the consumer.
  Table 6 - COMMENT Attributes
  *Note
  Attribute Label
  Restrictions
  -
  DESCRIPTION
  c=1, r=ASCII, u=
  -
  EXTENDED-ATTRIBUTES
  r=OBJREF, u=
  1
  
  TEXT
  c=1, r=ASCII, u= *Notes:
  
  
  
  • 1 TEXT contains arbitrary text.
  
  10.4 - COMPUTATIONA COMPUTATION object is similar to a PARAMETER object except that VALUES is considered to be the result of a computation using other recorded data. Consequently, a COMPUTATION may have PROPERTIES, and the data used to compute VALUES may be identified by SOURCE.
  Table 7 - COMPUTATION Attributes
  *Note
  Attribute Label
  Restrictions
  -
  DESCRIPTION
  c=1, r=ASCII, u=
  -
  EXTENDED-ATTRIBUTES
  r=OBJREF, u=
  -
  PROPERTIES
  r=IDENT | TIDENT, u=, v=(see Table\x111)
  1
  
  KIND
  c=1, r=ASCII | TASCII, u=, v=(see note)
  2
  
  DIMENSION
  r=ULONG, u=
  3
  
  AGGREGATE
  r=ULONG, u=
  4
  
  AXIS
  r=OBNAME, u=
  5
  
  ZONES
  r=OBNAME, u=
  6
  
  VALUES
  7
  
  SOURCE
  c=1, r=OBJREF, u= *Notes:
  
  
  
  • 1 KIND is a dictionary-controlled reference value that describes a general classification of the computation. Finer differentiation of the computation is provided by its identifier. Currently there are no reference values defined under the basic schema.
    
  • 2 DIMENSION is the same as PARAMETER:DIMENSION.
    
  • 3 AGGREGATE is the same as PARAMETER:AGGREGATE.
    
  • 4 AXIS is the same as PARAMETER:AXIS.
    
  • 5 ZONES is the same as PARAMETER:ZONES.
    
  • 6 VALUES is the same as PARAMETER:VALUES.
    
  • 7 SOURCE is a reference to another object that describes the immediate computational source of data recorded in this object. A typical SOURCE for a COMPUTATION object is a PROCESS object.
  
  10.5 - FRAME
  file:///C:/Documents%20and%20Settings/Administrator/桌面/RP66V2_20030702/rp66v2_sec6_fig2.gif
  Figure 2 - A Frame Block A FRAME object describes a frame type, which is a sequence of one or more frames written in one or more frame blocks (see Figure\x112). A frame block may contain one or more frames. A frame block is an IFLR for which the data descriptor reference is the name of a FRAME object. The layout of data in a frame and its frame block is determined by information in the referenced FRAME object. The frame block IFLRs of a frame type are not required to be contiguous and may be intermixed with other logical records.
  Conceptually, a frame is a set of channel values (see 10.2) occurring in the same order that their corresponding CHANNEL objects are listed in the CHANNELS attribute. Each channel represented in a frame block has one value per frame. Its values are written contiguously, followed by the values of the next channel, and so on. The first value of a channel belongs to the first frame in the frame block, the second value to the second frame, and so on. The maximum number of frames allowed per frame block is declared by attribute FRAMES-PER-IFLR-LIMIT or is assumed to be 1 if this attribute is absent. The actual number of frames in a frame block is written immediately following the IFLR modifier and has representation code ULONG.
  Each frame has a frame number. The frame numbers of all the frames in a frame block are written together in order immediately following the number of frames value and have representation code ULONG.
  A channel shall have the same number of elements per value for all frames of a frame type unless its CHANNEL object declares the value to be explicitly-sized via its FLAGS attribute. When one or more channels in a frame type are explicitly-sized, then each frame block will have channel value size information written immediately following the frame numbers array. Channel value size information applies only to the current frame block and is written in the form of dimension or aggregate descriptors, which are arrays of ULONG values (see Part 7). Only descriptors of explicitly-sized channels are written, and they are written in the same order as the channel values.
  The first channel value immediately follows the size descriptors. If there are no size descriptors it follows the last frame number.
  A frame type represents a grouping of channels having the same number of values (where a value may be a simple element or an array having many elements) and sharing one or more common indexes. A frame, being a selection of the nth value from each channel, represents a sampling of the channels at a given index value. One common index, for example, is frame number, which corresponds to sample number. Often a more meaningful index, for example time or depth, is provided as one of the channels in the frame type. Multiple indexes are possible this way.
  The FRAME object supports an additional implicit indexing mechanism. By means of its DIMENSION and AXIS attributes, the FRAME object may define an array representing the points of a grid having one or more coordinate axes (see Figure\x113). The grid may be used as an indexing domain whose points are associated with frames by means of the frame number. The grid may be bounded or unbounded. If DIMENSION and AXIS have the same count, the grid is bounded. AXIS count is allowed to be one greater than DIMENSION count, provided the last referenced AXIS object has numeric COORDINATES and non-zero SPACING, in which case the grid is unbounded along the last coordinate. The mapping of frame number to grid follows the pattern for dimensioned arrays specified in 8.1.2. Note that this pattern also applies when the last coordinate is unbounded (i.e., when DIMENSION count is one less than AXIS count). DIMENSION may be absent or have count = 0 when AXIS count = 1, which represents the simplest unbounded grid: a 1-dimensional array. If the grid is bounded and frame number exceeds its extent, then mapping should wrap back to the beginning of the grid.
  file:///C:/Documents%20and%20Settings/Administrator/桌面/RP66V2_20030702/rp66v2_sec6_fig3.gif
  Figure 3 - An Unbounded Grid of Frame Type Indexes Table 8 describes the attributes of a FRAME object.
  Table 8 - FRAME Attributes
  *Note
  Attribute Label
  Restrictions
  -
  DESCRIPTION
  c=1, r=ASCII, u=
  -
  EXTENDED-ATTRIBUTES
  r=OBJREF, u=
  1
  
  FLAGS
  r=IDENT | TIDENT, u=, v=(see note)
  2
  
  CHANNELS
  r=OBNAME, u=
  3
  
  FRAMES-PER-IFLR-LIMIT
  c=1, r=ULONG, u=
  4
  
  MIN-FRAME-NUMBER
  c=1, r=ULONG, u=
  5
  
  MAX-FRAME-NUMBER
  c=1, r=ULONG, u=
  6
  
  NUMBER-OF-FRAMES
  c=1, r=ULONG, u=
  7
  
  DIMENSION
  r=ULONG, u=
  8
  
  AXIS
  r=OBNAME, u= *Notes:
  
  
  
  • 1 FLAGS is a dictionary-controlled list of reference values that describe recording options for the frame type. Reference values are listed in Part 7.
    
  • 2 CHANNELS is a list of references to CHANNEL objects that describe the channel instances in the frame type. Channels occur in the frame type in the same order their corresponding CHANNEL objects are listed in this attribute. This attribute is required.
    
  • 3 FRAMES-PER-IFLR-LIMIT is the maximum number of frames per IFLR (i.e., per frame block) for this frame type. If absent, 1 is assumed. If present, it shall be a positive integer.
    
  • 4 MIN-FRAME-NUMBER is the minimum frame number for the frame type. It may be greater than 1.
    
  • 5 MAX-FRAME-NUMBER is the maximum frame number for the frame type.
    
  • 6 NUMBER-OF-FRAMES is the total number of frames written for the frame type.
    
  • 7 DIMENSION describes the bounded portion of a grid used as an indexing domain for the frame type (see 10.5.7).
    
  • 8 AXIS is a list of references to AXIS objects that describe a grid used as an indexing domain for the frame type (see 10.5.7). AXIS count must be at least as big as DIMENSION count and may be one greater. If AXIS count = DIMENSION count, the indexing grid is bounded. Otherwise, the indexing grid is unbounded. When both MIN-FRAME-NUMBER and MAX-FRAME-NUMBER are present, then NUMBER-OF-FRAMES may be derived only if FLAGS does not declare frame numbers to be UNORDERED.
  
  10.6 - GROUPA GROUP object describes an application-defined grouping of other objects.
  Table 9 - GROUP Attributes
  *Note
  Attribute Label
  Restrictions
  -
  DESCRIPTION
  c=1, r=ASCII, u=
  -
  EXTENDED-ATTRIBUTES
  r=OBJREF, u=
  1
  
  OBJECT-TYPE
  c=1, r=IDENT | TIDENT, u=
  2
  
  OBJECT-LIST
  r=OBJREF, u=
  3
  
  GROUP-LIST
  r=OBNAME, u= *Notes:
  
  
  
  • 1 OBJECT-TYPE specifies the object type referenced by OBJECT-LIST when OBJECT-LIST has representation code OBNAME (which belongs to the same class as OBJREF).
    
  • 2 OBJECT-LIST is a list of references to objects that belong to the group.
    
  • 3 GROUP-LIST is a list of references to other GROUP objects, which are used to extend the membership of the current GROUP object.
  
  10.7 - NO-FORMATA NO-FORMAT object identifies IFLRs that contain unformatted data, i.e., for which no format description is provided other than a name.
  Each IFLR having the name of a given NO-FORMAT object as its data descriptor reference contains a part of the unformatted data as the remainder of the logical record body following the IFLR modifier. The original data may be recovered by reading the IFLRs containing the data parts in the same order in which they were written and the bytes of each part as though they were USHORT.
  Table 10 - NO-FORMAT Attributes
  *Note
  Attribute Label
  Restrictions
  -
  DESCRIPTION
  c=1, r=ASCII, u=
  -
  EXTENDED-ATTRIBUTES
  r=OBJREF, u=
  1
  
  CONSUMER-NAME
  c=1, r=ASCII, u= *Notes:
  
  
  
  • 1 CONSUMER-NAME is a user-provided name for the data, for example an external file specification.
  
  10.8 - ORIGIN-TRANSLATIONAn ORIGIN-TRANSLATION object is used to maintain an origin translation table for encrypted logical records (see Part 2). ORIGIN-TRANSLATION sets shall not be encrypted.
  When a logical file has encrypted records, either EFLR or IFLR, one or more ORIGIN-TRANSLATION objects shall be written that contain the origin values used in the encrypted records. An encrypted record contains a translation tag in its first logical record segment header. This tag is the name of an ORIGIN-TRANSLATION object. The referenced object, which shall be present in the same logical file, shall contain all distinct origin values used in the encrypted record. When a data editing or merge operation requires origin translation and the encrypted record is copied without first being decrypted, the origin values it contains cannot be translated. However, if there is an ORIGIN-TRANSLATION object, its TRANSLATED-ORIGINS may be translated, and HIDDEN-ORIGINS preserved. In addition, the origin value in the translation tag may be translated if necessary to preserve the reference to its ORIGIN-TRANSLATION object. Subsequently when the edited or merged data is read by an application that can decrypt the encrypted record, its origins can be translated at that time using the appropriate ORIGIN-TRANSLATION object. At the same time, the HIDDEN-ORIGINS may be translated simply by replacing them with the corresponding TRANSLATED-ORIGINS values.
  Table 11 - ORIGIN-TRANSLATION Attributes
  *Note
  Attribute Label
  Restrictions
  -
  DESCRIPTION
  c=1, r=ASCII, u=
  -
  EXTENDED-ATTRIBUTES
  r=OBJREF, u=
  1
  
  HIDDEN-ORIGINS
  r=ULONG, u=
  2
  
  TRANSLATED-ORIGINS
  r=ORIGIN, u= *Notes:
  
  
  
  • 1 HIDDEN-ORIGINS is a list of untranslated origin values that may be in encrypted records.
    
  • 2 TRANSLATED-ORIGINS is a list of translated origin values corresponding to HIDDEN-ORIGINS.
  
  10.9 - PARAMETERA PARAMETER object describes a parameter that may consist of a single unzoned value or may consist of one or more zoned values. An unzoned value has no domain. It is globally defined. A zoned value is defined only in a specific domain described by a corresponding ZONE object (see Table\x1115).
  Table 12 - PARAMETER Attributes
  *Note
  Attribute Label
  Restrictions
  -
  DESCRIPTION
  c=1, r=ASCII, u=
  -
  EXTENDED-ATTRIBUTES
  r=OBJREF, u=
  1
  
  KIND
  c=1, r=ASCII | TASCII, u=, v=(see note)
  2
  
  DIMENSION
  r=ULONG, u=
  3
  
  AGGREGATE
  r=ULONG, u=
  4
  
  AXIS
  r=OBNAME, u=
  5
  
  ZONES
  r=OBNAME, u=
  6
  
  VALUES *Notes:
  
  
  
  • 1 KIND is a dictionary-controlled reference value that describes a general classification of the parameter. Finer differentiation of the parameter is provided by its identifier. Currently there are no reference values defined under the basic schema.
    
  • 2 DIMENSION specifies the structure of each of one or more values in VALUES (see Table\x111).
    
  • 3 AGGREGATE specifies the structure of each of one or more values in VALUES (see Table\x111).
    
  • 4 AXIS applies to each of one or more values in VALUES (see Table\x111).
    
  • 5 ZONES is a list of references to ZONE objects that specify mutually exclusive domains in which corresponding parameter values are defined. When ZONES is absent, the parameter is unzoned. When ZONES is present its count shall be positive.
    
  • 6 VALUES consists of zero or more parameter values. The extent of each value (i.e., number of elements) is determined by DIMENSION or AGGREGATE. If both are absent, each value has one element. If the parameter is zoned and VALUES count > 0, then the number of values is given by ZONES count. VALUES may have count = 0, in which case it is described by its characteristics and the other attributes (including ZONES, which may have non-zero count), but it has no values. This attribute is required.
  
  10.10 - PROCESSA PROCESS object describes a process by which other data was acquired or computed, including declarations of input data, output data, and parameters.
  Table 13 - PROCESS Attributes
  *Note
  Attribute Label
  Restrictions
  -
  DESCRIPTION
  c=1, r=ASCII, u=
  -
  EXTENDED-ATTRIBUTES
  r=OBJREF, u=
  -
  PROPERTIES
  r=IDENT | TIDENT, u=, v=(see Table\x111)
  1
  
  KIND
  c=1, r=ASCII | TASCII, u=, v=(see note)
  2
  
  TRADEMARK-NAME
  c=1, r=ASCII, u=
  3
  
  VERSION
  c=1, r=ASCII, u=
  4
  
  STATUS
  c=1, r=IDENT, u=, v=(see note)
  5
  
  INPUT-CHANNELS
  r=OBNAME, u=
  6
  
  OUTPUT-CHANNELS
  r=OBNAME, u=
  7
  
  INPUT-COMPUTATIONS
  r=OBNAME, u=
  8
  
  OUTPUT-COMPUTATIONS
  r=OBNAME, u=
  9
  
  PARAMETERS
  r=OBNAME, u=
  10
  
  COMMENTS
  r=ASCII, u= *Notes:
  
  
  
  • 1 KIND is a dictionary-controlled reference value that describes a general classification of the process . Finer differentiation of the process is provided by its identifier. Currently there are no reference values defined under the basic schema.
    
  • 2 TRADEMARK-NAME is the name used by the producer to refer to the process and its products.
    
  • 3 VERSION is the producer's software version of the process.
    
  • 4 STATUS is a reference value indicating the status of the process at the time this object was written (see Part 7).
    
  • 5 INPUT-CHANNELS is a list of references to CHANNEL objects that describe channels used directly by this process.
    
  • 6 OUTPUT-CHANNELS is a list of references to CHANNEL objects that describe channels produced directly by this process. The same CHANNEL object shall not appear in the OUTPUT-CHANNELS attribute of more than one PROCESS object in the same logical file.
    
  • 7 INPUT-COMPUTATIONS is a list of references to COMPUTATION objects that describe computed results used directly by this process.
    
  • 8 OUTPUT-COMPUTATIONS is a list of references to COMPUTATION objects that describe computed results produced directly by this process. The same COMPUTATION object shall not appear in the OUTPUT-COMPUTATIONS attribute of more than one PROCESS object in the same logical file.
    
  • 9 PARAMETERS is a list of references to PARAMETER objects that describe parameters used directly by this process or that affect the operation of this process. PARAMETER objects may appear in the PARAMETERS attribute of more than one PROCESS object in the same logical file.
    
  • 10 COMMENTS contains textual information about the process.
  
  10.11 - UPDATEAn UPDATE object is used to indicate a change in the value of an attribute previously written in the same logical file. Not all attributes may be updated, since managing updates in general can be costly. Updatable attributes of the basic schema are listed in Table\x1116.
  When present, attributes TIME, FRAME-TYPES, and FRAME-NUMBERS indicate when the change takes effect, in which case the attribute is considered to have the new value beginning at some time or point in the data and the old value prior to that point. In this case, the UPDATE object shall be written so that its new value applies only to data that follows it (but not necessarily to all data that follows it). When TIME, FRAME-TYPES, and FRAME-NUMBERS are all absent, then the meaning and use of the update is application-defined.
  Table 14 - UPDATE Attributes
  *Note
  Attribute Label
  Restrictions
  -
  DESCRIPTION
  c=1, r=ASCII, u=
  -
  EXTENDED-ATTRIBUTES
  r=OBJREF, u=
  1
  
  ATTRIBUTE
  c=1, r=ATTREF, u=
  2
  
  NEW
  -
  3
  
  OLD
  -
  4
  
  TIME
  c=1, r=DTIME | FDOUBL
  5
  
  FRAME-TYPES
  r=OBNAME, u=
  6
  
  FRAME-NUMBERS
  r=ULONG, u=
  7
  
  COMMENT
  c=1, r=ASCII, u= *Notes:
  
  
  
  • 1 ATTRIBUTE is the attribute being updated. This attribute is required.
    
  • 2 NEW is the new value of ATTRIBUTE. NEW may be absent, but OLD and NEW shall not both be absent.
    
  • 3 OLD is the previous value of ATTRIBUTE. OLD may be absent, but OLD and NEW shall not both be absent.
    
  • 4 TIME indicates when the change takes effect. Unless r=DTIME, this is an elapsed time from ORIGIN:CREATION-TIME. The attribute has the new value starting at the specified time and the old value prior to it.
    
  • 5 FRAME-TYPES is a list of names of one or more FRAME objects representing frame types to which the update is correlated.
    
  • 6 FRAME-NUMBERS is a list of one or more frame numbers indicating for each frame type in FRAME-TYPES at which frame the change takes effect. The attribute has the new value starting at the specified frame number and the old value for earlier frame numbers. Count of this attribute shall match count of FRAME-TYPES.
    
  • 7 COMMENT is additional textual information associated with the update.
  The UPDATE object type has been considerably simplified from RP66 V1. All well log related attributes have been removed along with TAG-CHANNEL and TAG-VALUE. The latter were considered unnecessary, since most applications are capable of determining frame numbers from channel values and vice-versa. Note also in Table\x1116 that several attributes previously declared updatable are no longer so. For some attributes, other mechanisms replaced the need for updates. Explicitly-sized channels and the ability to reference channels from AXIS objects removed the need to update attributes of CHANNEL and AXIS object types. Neither OLD nor NEW is a required attribute, since it is possible that an update may be made with the intent of changing an absent attribute to a value or vice-versa.
  10.12 - ZONEA ZONE object is used to identify an interval over which a value is defined or valid.
  Table 15 - ZONE Attributes
  *Note
  Attribute Label
  Restrictions
  -
  DESCRIPTION
  c=1, r=ASCII, u=
  -
  EXTENDED-ATTRIBUTES
  r=OBJREF, u=
  1
  
  DOMAIN
  c=1, r=IDENT | TIDENT, u=, v=(see note)
  2
  
  MAXIMUM
  c=1
  3
  
  MINIMUM
  c=1 *Notes:
  
  
  
  • 1 DOMAIN is a reference value that indicates the type of zone interval. There are currently no reference values defined under the basic schema. DOMAIN shall be consistent with the units and representation code of MAXIMUM and MINIMUM. DOMAIN may be absent, in which case the units of MAXIMUM or MINIMUM imply a generic domain.
    
  • 2 MAXIMUM is the maximum value of the zone. This value is not included in the zone. When absent, the zone is considered to extend indefinitely in the increasing direction.
    
  • 3 MINIMUM is the minimum value of the zone. This value is included in the zone. When absent, the zone is considered to extend indefinitely in the decreasing direction.
  
  10.13 - UPDATABLE ATTRIBUTESTable 16 lists attributes of the basic schema that may be updated using UPDATE objects.
  Table 16 - Updatable Attributes
  *Note
  Object Type
  Attribute Label
  1
  
  PARAMETER
  VALUES
  2
  
  PROCESS
  STATUS *Notes:
  
  
  
  • 1 The VALUES attribute may be updated if and only if the parameter is unzoned, i.e., if and only if the ZONES attribute is absent.
    
  • 2 STATUS of a process may change during the course of acquiring or computing data written to a logical file.
  The width of each channel value illustrates the number of elements per value. A 1-level aggregate: Simple array A 2-level aggregate: Array of arrays A 3-level aggregate: Array of array of arrays Note that the number of elements of Value is the sum of the sizes of the level n arrays, and the number of level n arrays is the sum of the numbers of the level n-1 arrays.

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/94574/showart_1900121.html