chore: Update discovery artifacts

docs/dyn/addressvalidation_v1.v1.html

@@ -123,7 +123,7 @@ <h3>Method Details</h3>
     The object takes the form of:
 
 { # The request for validating an address.
-  &quot;address&quot;: { # Represents a postal address (for example, 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 by user input or from importing existing data, depending on the type of process. Advice on address input or 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, see: https://support.google.com/business/answer/6397478. # Required. The address being validated. Unformatted addresses should be submitted via `address_lines`. The total length of the fields in this input must not exceed 280 characters. Supported regions can be found [here](https://developers.google.com/maps/documentation/address-validation/coverage). The language_code value in the input address is reserved for future uses and is ignored today. The validated address result will be populated based on the preferred language for the given address, as identified by the system. The Address Validation API ignores the values in recipients and organization. Any values in those fields will be discarded and not returned. Please do not set them.
+  &quot;address&quot;: { # Represents a postal address, such as for postal delivery or payments addresses. With a postal address, a postal service can deliver items to a premise, P.O. box, or similar. A postal address is not intended to model geographical locations like roads, towns, or mountains. In typical usage, an address would be created by user input or from importing existing data, depending on the type of process. Advice on address input or 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, see: https://support.google.com/business/answer/6397478. # Required. The address being validated. Unformatted addresses should be submitted via `address_lines`. The total length of the fields in this input must not exceed 280 characters. Supported regions can be found [here](https://developers.google.com/maps/documentation/address-validation/coverage). The language_code value in the input address is reserved for future uses and is ignored today. The validated address result will be populated based on the preferred language for the given address, as identified by the system. The Address Validation API ignores the values in recipients and organization. Any values in those fields will be discarded and not returned. Please do not set them.
     &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 (for example, &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 or region of the address. In places where this can vary (for example, Japan), `address_language` is used to make it explicit (for example, &quot;ja&quot; for large-to-small ordering and &quot;ja-Latn&quot; or &quot;en&quot; for small-to-large). In 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).
       &quot;A String&quot;,
     ],
@@ -178,7 +178,7 @@ <h3>Method Details</h3>
       &quot;missingComponentTypes&quot;: [ # The types of components that were expected to be present in a correctly formatted mailing address but were not found in the input AND could not be inferred. An example might be `[&#x27;street_number&#x27;, &#x27;route&#x27;]` for an input like &quot;Boulder, Colorado, 80301, USA&quot;. The list of possible types can be found [here](https://developers.google.com/maps/documentation/geocoding/requests-geocoding#Types). **Note: you might see a missing component type when you think you&#x27;ve already supplied the missing component.** For example, this can happen when the input address contains the building name, but not the premise number. In the address &quot;渋谷区渋谷３丁目　Shibuya Stream&quot;, the building name &quot;Shibuya Stream&quot; has the component type `premise`, but the premise number is missing, so `missing_component_types` will contain `premise`.
         &quot;A String&quot;,
       ],
-      &quot;postalAddress&quot;: { # Represents a postal address (for example, 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 by user input or from importing existing data, depending on the type of process. Advice on address input or 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, see: https://support.google.com/business/answer/6397478. # The post-processed address represented as a postal address.
+      &quot;postalAddress&quot;: { # Represents a postal address, such as for postal delivery or payments addresses. With a postal address, a postal service can deliver items to a premise, P.O. box, or similar. A postal address is not intended to model geographical locations like roads, towns, or mountains. In typical usage, an address would be created by user input or from importing existing data, depending on the type of process. Advice on address input or 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, see: https://support.google.com/business/answer/6397478. # The post-processed address represented as a postal address.
         &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 (for example, &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 or region of the address. In places where this can vary (for example, Japan), `address_language` is used to make it explicit (for example, &quot;ja&quot; for large-to-small ordering and &quot;ja-Latn&quot; or &quot;en&quot; for small-to-large). In 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).
           &quot;A String&quot;,
         ],
@@ -221,7 +221,7 @@ <h3>Method Details</h3>
       &quot;missingComponentTypes&quot;: [ # The types of components that were expected to be present in a correctly formatted mailing address but were not found in the input AND could not be inferred. An example might be `[&#x27;street_number&#x27;, &#x27;route&#x27;]` for an input like &quot;Boulder, Colorado, 80301, USA&quot;. The list of possible types can be found [here](https://developers.google.com/maps/documentation/geocoding/requests-geocoding#Types). **Note: you might see a missing component type when you think you&#x27;ve already supplied the missing component.** For example, this can happen when the input address contains the building name, but not the premise number. In the address &quot;渋谷区渋谷３丁目　Shibuya Stream&quot;, the building name &quot;Shibuya Stream&quot; has the component type `premise`, but the premise number is missing, so `missing_component_types` will contain `premise`.
         &quot;A String&quot;,
       ],
-      &quot;postalAddress&quot;: { # Represents a postal address (for example, 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 by user input or from importing existing data, depending on the type of process. Advice on address input or 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, see: https://support.google.com/business/answer/6397478. # The post-processed address represented as a postal address.
+      &quot;postalAddress&quot;: { # Represents a postal address, such as for postal delivery or payments addresses. With a postal address, a postal service can deliver items to a premise, P.O. box, or similar. A postal address is not intended to model geographical locations like roads, towns, or mountains. In typical usage, an address would be created by user input or from importing existing data, depending on the type of process. Advice on address input or 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, see: https://support.google.com/business/answer/6397478. # The post-processed address represented as a postal address.
         &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 (for example, &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 or region of the address. In places where this can vary (for example, Japan), `address_language` is used to make it explicit (for example, &quot;ja&quot; for large-to-small ordering and &quot;ja-Latn&quot; or &quot;en&quot; for small-to-large). In 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).
           &quot;A String&quot;,
         ],

docs/dyn/adsenseplatform_v1alpha.accounts.platforms.childAccounts.sites.html

@@ -77,6 +77,9 @@ <h2>Instance Methods</h2>
 <p class="toc_element">
   <code><a href="#close">close()</a></code></p>
 <p class="firstline">Close httplib2 connections.</p>
+<p class="toc_element">
+  <code><a href="#get">get(name, x__xgafv=None)</a></code></p>
+<p class="firstline">Gets a Platform Child Site for a specified Platform Child Account and site.</p>
 <p class="toc_element">
   <code><a href="#list">list(parent, pageSize=None, pageToken=None, x__xgafv=None)</a></code></p>
 <p class="firstline">Lists Platform Child Sites for a specified Platform Child Account.</p>
@@ -92,6 +95,27 @@ <h3>Method Details</h3>
   <pre>Close httplib2 connections.</pre>
 </div>
 
+<div class="method">
+    <code class="details" id="get">get(name, x__xgafv=None)</code>
+  <pre>Gets a Platform Child Site for a specified Platform Child Account and site.
+
+Args:
+  name: string, Required. The name of the platform child site to retrieve. Format: accounts/{account}/platforms/{platform}/childAccounts/{child_account}/sites/{platform_child_site} (required)
+  x__xgafv: string, V1 error format.
+    Allowed values
+      1 - v1 error format
+      2 - v2 error format
+
+Returns:
+  An object of the form:
+
+    { # Representation of a Transparent Platform Child Site.
+  &quot;domain&quot;: &quot;A String&quot;, # Output only. Domain URL of the Platform Child Site. Part of the PlatformChildSite name.
+  &quot;name&quot;: &quot;A String&quot;, # Identifier. Format: accounts/{account}/platforms/{platform}/childAccounts/{child_account}/sites/{platform_child_site}
+  &quot;platformGroup&quot;: &quot;A String&quot;, # Resource name of the Platform Group of the Platform Child Site.
+}</pre>
+</div>
+
 <div class="method">
     <code class="details" id="list">list(parent, pageSize=None, pageToken=None, x__xgafv=None)</code>
   <pre>Lists Platform Child Sites for a specified Platform Child Account.

docs/dyn/adsenseplatform_v1alpha.accounts.platforms.groups.html

@@ -77,6 +77,9 @@ <h2>Instance Methods</h2>
 <p class="toc_element">
   <code><a href="#close">close()</a></code></p>
 <p class="firstline">Close httplib2 connections.</p>
+<p class="toc_element">
+  <code><a href="#get">get(name, x__xgafv=None)</a></code></p>
+<p class="firstline">Gets a Platform Group for a specified Platform and group.</p>
 <p class="toc_element">
   <code><a href="#list">list(parent, pageSize=None, pageToken=None, x__xgafv=None)</a></code></p>
 <p class="firstline">Lists Platform Groups for a specified Platform.</p>
@@ -89,6 +92,29 @@ <h3>Method Details</h3>
   <pre>Close httplib2 connections.</pre>
 </div>
 
+<div class="method">
+    <code class="details" id="get">get(name, x__xgafv=None)</code>
+  <pre>Gets a Platform Group for a specified Platform and group.
+
+Args:
+  name: string, Required. The name of the platform group to retrieve. Format: accounts/{account}/platforms/{platform}/groups/{group} (required)
+  x__xgafv: string, V1 error format.
+    Allowed values
+      1 - v1 error format
+      2 - v2 error format
+
+Returns:
+  An object of the form:
+
+    { # Representation of a Transparent Platform Group.
+  &quot;description&quot;: &quot;A String&quot;, # Output only. Description of the PlatformGroup.
+  &quot;name&quot;: &quot;A String&quot;, # Identifier. Format: accounts/{account}/platforms/{platform}/groups/{platform_group}
+  &quot;revshareMillipercent&quot;: { # A representation of a decimal value, such as 2.5. Clients may convert values into language-native decimal formats, such as Java&#x27;s [BigDecimal](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/math/BigDecimal.html) or Python&#x27;s [decimal.Decimal](https://docs.python.org/3/library/decimal.html). # The revenue share of the PlatformGroup, in millipercent (e.g. 15000 = 15%).
+    &quot;value&quot;: &quot;A String&quot;, # The decimal value, as a string. The string representation consists of an optional sign, `+` (`U+002B`) or `-` (`U+002D`), followed by a sequence of zero or more decimal digits (&quot;the integer&quot;), optionally followed by a fraction, optionally followed by an exponent. An empty string **should** be interpreted as `0`. The fraction consists of a decimal point followed by zero or more decimal digits. The string must contain at least one digit in either the integer or the fraction. The number formed by the sign, the integer and the fraction is referred to as the significand. The exponent consists of the character `e` (`U+0065`) or `E` (`U+0045`) followed by one or more decimal digits. Services **should** normalize decimal values before storing them by: - Removing an explicitly-provided `+` sign (`+2.5` -&gt; `2.5`). - Replacing a zero-length integer value with `0` (`.5` -&gt; `0.5`). - Coercing the exponent character to upper-case, with explicit sign (`2.5e8` -&gt; `2.5E+8`). - Removing an explicitly-provided zero exponent (`2.5E0` -&gt; `2.5`). Services **may** perform additional normalization based on its own needs and the internal decimal implementation selected, such as shifting the decimal point and exponent value together (example: `2.5E-1` &lt;-&gt; `0.25`). Additionally, services **may** preserve trailing zeroes in the fraction to indicate increased precision, but are not required to do so. Note that only the `.` character is supported to divide the integer and the fraction; `,` **should not** be supported regardless of locale. Additionally, thousand separators **should not** be supported. If a service does support them, values **must** be normalized. The ENBF grammar is: DecimalString = &#x27;&#x27; | [Sign] Significand [Exponent]; Sign = &#x27;+&#x27; | &#x27;-&#x27;; Significand = Digits &#x27;.&#x27; | [Digits] &#x27;.&#x27; Digits; Exponent = (&#x27;e&#x27; | &#x27;E&#x27;) [Sign] Digits; Digits = { &#x27;0&#x27; | &#x27;1&#x27; | &#x27;2&#x27; | &#x27;3&#x27; | &#x27;4&#x27; | &#x27;5&#x27; | &#x27;6&#x27; | &#x27;7&#x27; | &#x27;8&#x27; | &#x27;9&#x27; }; Services **should** clearly document the range of supported values, the maximum supported precision (total number of digits), and, if applicable, the scale (number of digits after the decimal point), as well as how it behaves when receiving out-of-bounds values. Services **may** choose to accept values passed as input even when the value has a higher precision or scale than the service supports, and **should** round the value to fit the supported scale. Alternatively, the service **may** error with `400 Bad Request` (`INVALID_ARGUMENT` in gRPC) if precision would be lost. Services **should** error with `400 Bad Request` (`INVALID_ARGUMENT` in gRPC) if the service receives a value outside of the supported range.
+  },
+}</pre>
+</div>
+
 <div class="method">
     <code class="details" id="list">list(parent, pageSize=None, pageToken=None, x__xgafv=None)</code>
   <pre>Lists Platform Groups for a specified Platform.