feat(documentai): update the api

#### documentai:v1

The following keys were deleted:
- schemas.GoogleCloudDocumentaiV1EntityTypeMetadata.properties.prefixedNamingOnProperties.type (Total Keys: 1)

The following keys were added:
- schemas.GoogleCloudDocumentaiV1DocumentOutputConfigGcsOutputConfig.properties.fieldMask (Total Keys: 2)

#### documentai:v1beta3

The following keys were deleted:
- schemas.GoogleCloudDocumentaiV1beta3EntityTypeMetadata.properties.prefixedNamingOnProperties.type (Total Keys: 1)

The following keys were added:
- schemas.GoogleCloudDocumentaiV1beta3DocumentOutputConfigGcsOutputConfig.properties.fieldMask (Total Keys: 2)

Author: yoshi-automation

docs/dyn/documentai_v1.projects.locations.processors.html

@@ -130,6 +130,7 @@ <h3>Method Details</h3>
 { # Request message for batch process document method.
   &quot;documentOutputConfig&quot;: { # Config that controls the output of documents. All documents will be written as a JSON file. # The overall output config for batch process.
     &quot;gcsOutputConfig&quot;: { # The configuration used when outputting documents. # Output config to write the results to Cloud Storage.
+      &quot;fieldMask&quot;: &quot;A String&quot;, # Specifies which fields to include in the output documents.
       &quot;gcsUri&quot;: &quot;A String&quot;, # The Cloud Storage uri (a directory) of the output.
     },
   },
@@ -431,7 +432,7 @@ <h3>Method Details</h3>
         &quot;confidence&quot;: 3.14, # Optional. Confidence of detected Schema entity. Range [0, 1].
         &quot;id&quot;: &quot;A String&quot;, # Optional. Canonical id. This will be a unique value in the entity list for this document.
         &quot;mentionId&quot;: &quot;A String&quot;, # Optional. Deprecated. Use `id` field instead.
-        &quot;mentionText&quot;: &quot;A String&quot;, # Optional. Text value in the document e.g. `1600 Amphitheatre Pkwy`. If the entity is not present in the document, this field will be empty.
+        &quot;mentionText&quot;: &quot;A String&quot;, # Optional. Text value of the entity e.g. `1600 Amphitheatre Pkwy`.
         &quot;normalizedValue&quot;: { # Parsed and normalized entity value. # Optional. Normalized entity value. Absent if the extracted value could not be converted or the type (e.g. address) is not supported for certain parsers. This field is also only populated for certain supported document types.
           &quot;addressValue&quot;: { # Represents a postal address, e.g. for postal delivery or payments addresses. Given a postal address, a postal service can deliver items to a premise, P.O. Box or similar. It is not intended to model geographical locations (roads, towns, mountains). In typical usage an address would be created via user input or from importing existing data, depending on the type of process. Advice on address input / editing: - Use an internationalization-ready address widget such as https://github.com/google/libaddressinput) - Users should not be presented with UI elements for input or editing of fields outside countries where that field is used. For more guidance on how to use this schema, please see: https://support.google.com/business/answer/6397478 # Postal address. See also: https://github.com/googleapis/googleapis/blob/master/google/type/postal_address.proto
             &quot;addressLines&quot;: [ # Unstructured address lines describing the lower levels of an address. Because values in address_lines do not have type information and may sometimes contain multiple values in a single field (e.g. &quot;Austin, TX&quot;), it is important that the line order is clear. The order of address lines should be &quot;envelope order&quot; for the country/region of the address. In places where this can vary (e.g. Japan), address_language is used to make it explicit (e.g. &quot;ja&quot; for large-to-small ordering and &quot;ja-Latn&quot; or &quot;en&quot; for small-to-large). This way, the most specific line of an address can be selected based on the language. The minimum permitted structural representation of an address consists of a region_code with all remaining information placed in the address_lines. It would be possible to format such an address very approximately without geocoding, but no semantic reasoning could be made about any of the address components until it was at least partially resolved. Creating an address only containing a region_code and address_lines, and then geocoding is the recommended way to handle completely unstructured addresses (as opposed to guessing which parts of the address should be localities or administrative areas).
@@ -1245,7 +1246,7 @@ <h3>Method Details</h3>
         &quot;confidence&quot;: 3.14, # Optional. Confidence of detected Schema entity. Range [0, 1].
         &quot;id&quot;: &quot;A String&quot;, # Optional. Canonical id. This will be a unique value in the entity list for this document.
         &quot;mentionId&quot;: &quot;A String&quot;, # Optional. Deprecated. Use `id` field instead.
-        &quot;mentionText&quot;: &quot;A String&quot;, # Optional. Text value in the document e.g. `1600 Amphitheatre Pkwy`. If the entity is not present in the document, this field will be empty.
+        &quot;mentionText&quot;: &quot;A String&quot;, # Optional. Text value of the entity e.g. `1600 Amphitheatre Pkwy`.
         &quot;normalizedValue&quot;: { # Parsed and normalized entity value. # Optional. Normalized entity value. Absent if the extracted value could not be converted or the type (e.g. address) is not supported for certain parsers. This field is also only populated for certain supported document types.
           &quot;addressValue&quot;: { # Represents a postal address, e.g. for postal delivery or payments addresses. Given a postal address, a postal service can deliver items to a premise, P.O. Box or similar. It is not intended to model geographical locations (roads, towns, mountains). In typical usage an address would be created via user input or from importing existing data, depending on the type of process. Advice on address input / editing: - Use an internationalization-ready address widget such as https://github.com/google/libaddressinput) - Users should not be presented with UI elements for input or editing of fields outside countries where that field is used. For more guidance on how to use this schema, please see: https://support.google.com/business/answer/6397478 # Postal address. See also: https://github.com/googleapis/googleapis/blob/master/google/type/postal_address.proto
             &quot;addressLines&quot;: [ # Unstructured address lines describing the lower levels of an address. Because values in address_lines do not have type information and may sometimes contain multiple values in a single field (e.g. &quot;Austin, TX&quot;), it is important that the line order is clear. The order of address lines should be &quot;envelope order&quot; for the country/region of the address. In places where this can vary (e.g. Japan), address_language is used to make it explicit (e.g. &quot;ja&quot; for large-to-small ordering and &quot;ja-Latn&quot; or &quot;en&quot; for small-to-large). This way, the most specific line of an address can be selected based on the language. The minimum permitted structural representation of an address consists of a region_code with all remaining information placed in the address_lines. It would be possible to format such an address very approximately without geocoding, but no semantic reasoning could be made about any of the address components until it was at least partially resolved. Creating an address only containing a region_code and address_lines, and then geocoding is the recommended way to handle completely unstructured addresses (as opposed to guessing which parts of the address should be localities or administrative areas).

docs/dyn/documentai_v1.projects.locations.processors.humanReviewConfig.html

@@ -114,7 +114,6 @@ <h3>Method Details</h3>
             &quot;enableValidation&quot;: True or False, # Whether to enable human review validation.
           },
           &quot;inactive&quot;: True or False, # Whether the entity type should be considered as &quot;inactive&quot;.
-          &quot;prefixedNamingOnProperties&quot;: True or False, # If set, the properties of this entity type must be prefixed with the parents.
         },
         &quot;enumValues&quot;: { # Defines the a list of enum values. # If specified, lists all the possible values for this entity. This should not be more than a handful of values. If the number of values is &gt;10 or could change frequently use the `EntityType.value_ontology` field and specify a list of all possible values in a value ontology file.
           &quot;values&quot;: [ # The individual values that this enum values type can include.
@@ -156,7 +155,7 @@ <h3>Method Details</h3>
         &quot;confidence&quot;: 3.14, # Optional. Confidence of detected Schema entity. Range [0, 1].
         &quot;id&quot;: &quot;A String&quot;, # Optional. Canonical id. This will be a unique value in the entity list for this document.
         &quot;mentionId&quot;: &quot;A String&quot;, # Optional. Deprecated. Use `id` field instead.
-        &quot;mentionText&quot;: &quot;A String&quot;, # Optional. Text value in the document e.g. `1600 Amphitheatre Pkwy`. If the entity is not present in the document, this field will be empty.
+        &quot;mentionText&quot;: &quot;A String&quot;, # Optional. Text value of the entity e.g. `1600 Amphitheatre Pkwy`.
         &quot;normalizedValue&quot;: { # Parsed and normalized entity value. # Optional. Normalized entity value. Absent if the extracted value could not be converted or the type (e.g. address) is not supported for certain parsers. This field is also only populated for certain supported document types.
           &quot;addressValue&quot;: { # Represents a postal address, e.g. for postal delivery or payments addresses. Given a postal address, a postal service can deliver items to a premise, P.O. Box or similar. It is not intended to model geographical locations (roads, towns, mountains). In typical usage an address would be created via user input or from importing existing data, depending on the type of process. Advice on address input / editing: - Use an internationalization-ready address widget such as https://github.com/google/libaddressinput) - Users should not be presented with UI elements for input or editing of fields outside countries where that field is used. For more guidance on how to use this schema, please see: https://support.google.com/business/answer/6397478 # Postal address. See also: https://github.com/googleapis/googleapis/blob/master/google/type/postal_address.proto
             &quot;addressLines&quot;: [ # Unstructured address lines describing the lower levels of an address. Because values in address_lines do not have type information and may sometimes contain multiple values in a single field (e.g. &quot;Austin, TX&quot;), it is important that the line order is clear. The order of address lines should be &quot;envelope order&quot; for the country/region of the address. In places where this can vary (e.g. Japan), address_language is used to make it explicit (e.g. &quot;ja&quot; for large-to-small ordering and &quot;ja-Latn&quot; or &quot;en&quot; for small-to-large). This way, the most specific line of an address can be selected based on the language. The minimum permitted structural representation of an address consists of a region_code with all remaining information placed in the address_lines. It would be possible to format such an address very approximately without geocoding, but no semantic reasoning could be made about any of the address components until it was at least partially resolved. Creating an address only containing a region_code and address_lines, and then geocoding is the recommended way to handle completely unstructured addresses (as opposed to guessing which parts of the address should be localities or administrative areas).

docs/dyn/documentai_v1.projects.locations.processors.processorVersions.html

@@ -114,6 +114,7 @@ <h3>Method Details</h3>
 { # Request message for batch process document method.
   &quot;documentOutputConfig&quot;: { # Config that controls the output of documents. All documents will be written as a JSON file. # The overall output config for batch process.
     &quot;gcsOutputConfig&quot;: { # The configuration used when outputting documents. # Output config to write the results to Cloud Storage.
+      &quot;fieldMask&quot;: &quot;A String&quot;, # Specifies which fields to include in the output documents.
       &quot;gcsUri&quot;: &quot;A String&quot;, # The Cloud Storage uri (a directory) of the output.
     },
   },
@@ -340,7 +341,7 @@ <h3>Method Details</h3>
         &quot;confidence&quot;: 3.14, # Optional. Confidence of detected Schema entity. Range [0, 1].
         &quot;id&quot;: &quot;A String&quot;, # Optional. Canonical id. This will be a unique value in the entity list for this document.
         &quot;mentionId&quot;: &quot;A String&quot;, # Optional. Deprecated. Use `id` field instead.
-        &quot;mentionText&quot;: &quot;A String&quot;, # Optional. Text value in the document e.g. `1600 Amphitheatre Pkwy`. If the entity is not present in the document, this field will be empty.
+        &quot;mentionText&quot;: &quot;A String&quot;, # Optional. Text value of the entity e.g. `1600 Amphitheatre Pkwy`.
         &quot;normalizedValue&quot;: { # Parsed and normalized entity value. # Optional. Normalized entity value. Absent if the extracted value could not be converted or the type (e.g. address) is not supported for certain parsers. This field is also only populated for certain supported document types.
           &quot;addressValue&quot;: { # Represents a postal address, e.g. for postal delivery or payments addresses. Given a postal address, a postal service can deliver items to a premise, P.O. Box or similar. It is not intended to model geographical locations (roads, towns, mountains). In typical usage an address would be created via user input or from importing existing data, depending on the type of process. Advice on address input / editing: - Use an internationalization-ready address widget such as https://github.com/google/libaddressinput) - Users should not be presented with UI elements for input or editing of fields outside countries where that field is used. For more guidance on how to use this schema, please see: https://support.google.com/business/answer/6397478 # Postal address. See also: https://github.com/googleapis/googleapis/blob/master/google/type/postal_address.proto
             &quot;addressLines&quot;: [ # Unstructured address lines describing the lower levels of an address. Because values in address_lines do not have type information and may sometimes contain multiple values in a single field (e.g. &quot;Austin, TX&quot;), it is important that the line order is clear. The order of address lines should be &quot;envelope order&quot; for the country/region of the address. In places where this can vary (e.g. Japan), address_language is used to make it explicit (e.g. &quot;ja&quot; for large-to-small ordering and &quot;ja-Latn&quot; or &quot;en&quot; for small-to-large). This way, the most specific line of an address can be selected based on the language. The minimum permitted structural representation of an address consists of a region_code with all remaining information placed in the address_lines. It would be possible to format such an address very approximately without geocoding, but no semantic reasoning could be made about any of the address components until it was at least partially resolved. Creating an address only containing a region_code and address_lines, and then geocoding is the recommended way to handle completely unstructured addresses (as opposed to guessing which parts of the address should be localities or administrative areas).
@@ -1154,7 +1155,7 @@ <h3>Method Details</h3>
         &quot;confidence&quot;: 3.14, # Optional. Confidence of detected Schema entity. Range [0, 1].
         &quot;id&quot;: &quot;A String&quot;, # Optional. Canonical id. This will be a unique value in the entity list for this document.
         &quot;mentionId&quot;: &quot;A String&quot;, # Optional. Deprecated. Use `id` field instead.
-        &quot;mentionText&quot;: &quot;A String&quot;, # Optional. Text value in the document e.g. `1600 Amphitheatre Pkwy`. If the entity is not present in the document, this field will be empty.
+        &quot;mentionText&quot;: &quot;A String&quot;, # Optional. Text value of the entity e.g. `1600 Amphitheatre Pkwy`.
         &quot;normalizedValue&quot;: { # Parsed and normalized entity value. # Optional. Normalized entity value. Absent if the extracted value could not be converted or the type (e.g. address) is not supported for certain parsers. This field is also only populated for certain supported document types.
           &quot;addressValue&quot;: { # Represents a postal address, e.g. for postal delivery or payments addresses. Given a postal address, a postal service can deliver items to a premise, P.O. Box or similar. It is not intended to model geographical locations (roads, towns, mountains). In typical usage an address would be created via user input or from importing existing data, depending on the type of process. Advice on address input / editing: - Use an internationalization-ready address widget such as https://github.com/google/libaddressinput) - Users should not be presented with UI elements for input or editing of fields outside countries where that field is used. For more guidance on how to use this schema, please see: https://support.google.com/business/answer/6397478 # Postal address. See also: https://github.com/googleapis/googleapis/blob/master/google/type/postal_address.proto
             &quot;addressLines&quot;: [ # Unstructured address lines describing the lower levels of an address. Because values in address_lines do not have type information and may sometimes contain multiple values in a single field (e.g. &quot;Austin, TX&quot;), it is important that the line order is clear. The order of address lines should be &quot;envelope order&quot; for the country/region of the address. In places where this can vary (e.g. Japan), address_language is used to make it explicit (e.g. &quot;ja&quot; for large-to-small ordering and &quot;ja-Latn&quot; or &quot;en&quot; for small-to-large). This way, the most specific line of an address can be selected based on the language. The minimum permitted structural representation of an address consists of a region_code with all remaining information placed in the address_lines. It would be possible to format such an address very approximately without geocoding, but no semantic reasoning could be made about any of the address components until it was at least partially resolved. Creating an address only containing a region_code and address_lines, and then geocoding is the recommended way to handle completely unstructured addresses (as opposed to guessing which parts of the address should be localities or administrative areas).