From c83c97add1ebdf8dda0d7205ff819d6f0b99af75 Mon Sep 17 00:00:00 2001 From: Shawn Alpay <77511110+shawnalpay@users.noreply.github.com> Date: Fri, 21 Nov 2025 10:13:04 -0800 Subject: [PATCH] initial pass --- ...t_utilization_without_commitment_discount_flexibility.md | 2 +- .../data_generator_version_changed_example.md | 2 +- .../metadata_examples/deprecating_columns_example.md | 2 +- .../appendix/metadata_examples/renaming_columns_example.md | 4 ++-- .../appendix/participating_entity_identification.md | 2 +- .../saas_examples/virtual_currency_pricing_model.md | 2 +- .../cost_and_usage/columns/allocatedmethoddetails.md | 6 +++--- .../datasets/cost_and_usage/columns/chargeclass.md | 2 +- .../datasets/cost_and_usage/columns/contractapplied.md | 2 +- specification/datasets/cost_and_usage/columns/invoiceid.md | 2 +- specification/datasets/cost_and_usage/columns/tags.md | 2 +- specification/metadata/metadata_overview.md | 2 +- specification/metadata/recency/dataset_instance_complete.md | 2 +- .../metadata/recency/time_sectors/time_sectors_overview.md | 2 +- specification/overview.md | 2 +- specification/spec_abstract.md | 2 +- specification/supported_features/contract_commitments.md | 2 +- .../supported_features/cost_and_usage_attribution.md | 2 +- .../datasets/cost_and_usage/columns/chargefrequency.md | 2 +- .../datasets/cost_and_usage/columns/invoiceid.md | 2 +- .../metadata/metadata_requirements_overview.md | 2 +- 21 files changed, 24 insertions(+), 24 deletions(-) diff --git a/specification/appendix/examples/commitment_discount_flexibility_examples/zero_percent_utilization_without_commitment_discount_flexibility.md b/specification/appendix/examples/commitment_discount_flexibility_examples/zero_percent_utilization_without_commitment_discount_flexibility.md index d6302d4d9..8301c494a 100644 --- a/specification/appendix/examples/commitment_discount_flexibility_examples/zero_percent_utilization_without_commitment_discount_flexibility.md +++ b/specification/appendix/examples/commitment_discount_flexibility_examples/zero_percent_utilization_without_commitment_discount_flexibility.md @@ -31,7 +31,7 @@ The above SKU Catalog shows that this service provider only has 1 service that o ## Outcome * 1 recurring, purchase record exists for 1 eligible "Hour" of the no upfront, *commitment discount* and incurs a $1.50 [*BilledCost*](#billedcost). -* The VM_LARGE *commitment discount* is unused for the correspending [*charge period*](#glossary:chargeperiod) because no VM_LARGE resources are running and incurs a $1.50 [*EffectiveCost*](#effectivecost). +* The VM_LARGE *commitment discount* is unused for the corresponding [*charge period*](#glossary:chargeperiod) because no VM_LARGE resources are running and incurs a $1.50 [*EffectiveCost*](#effectivecost). * 1 hour of on-demand usage is incurred by the VM_MEDIUM resource and incurs a $2.00 *BilledCost* and *EffectiveCost*. [CSV Example](/specification/data/commitment_discount_flexibility/zero_percent_utilization_without_commitment_discount_flexibility.csv) diff --git a/specification/appendix/metadata_examples/data_generator_version_changed_example.md b/specification/appendix/metadata_examples/data_generator_version_changed_example.md index 185e13565..afb6a0f66 100644 --- a/specification/appendix/metadata_examples/data_generator_version_changed_example.md +++ b/specification/appendix/metadata_examples/data_generator_version_changed_example.md @@ -2,7 +2,7 @@ ## Scenario -ACME specifies the optional metadata property [Data Generator Version](#datageneratorversion) in their [Schema](#schema) object. They made a change to the Cost and Usage [*FOCUS dataset*](#glossary:FOCUS-dataset) they produce that does not adopt a new FOCUS Version, nor does it make a change the included columns, but does impact values in the data. This example illustrates that Data Generator Version changes are independent of column changes, however data generator version changes may include column changes. +ACME specifies the optional metadata property [Data Generator Version](#datageneratorversion) in their [Schema](#schema) object. They made a change to the Cost and Usage [*FOCUS dataset*](#glossary:FOCUS-dataset) they produce that does not adopt a new FOCUS Version, nor does it make a change to the included columns, but does impact values in the data. This example illustrates that Data Generator Version changes are independent of column changes, however data generator version changes may include column changes. The data generator creates a new schema object to represent the new schema. The data generator includes both the FOCUS Version and Data Generator Version in the schema object. diff --git a/specification/appendix/metadata_examples/deprecating_columns_example.md b/specification/appendix/metadata_examples/deprecating_columns_example.md index 3ff5bd660..c81434117 100644 --- a/specification/appendix/metadata_examples/deprecating_columns_example.md +++ b/specification/appendix/metadata_examples/deprecating_columns_example.md @@ -69,7 +69,7 @@ The updated schema-related metadata could look like this: "DataType": "STRING", "StringMaxLength": 64, "StringEncoding": "UTF-8", - "Deprecation": true + "Deprecated": true } ] } diff --git a/specification/appendix/metadata_examples/renaming_columns_example.md b/specification/appendix/metadata_examples/renaming_columns_example.md index 9fa233ec6..564910c63 100644 --- a/specification/appendix/metadata_examples/renaming_columns_example.md +++ b/specification/appendix/metadata_examples/renaming_columns_example.md @@ -70,7 +70,7 @@ The updated schema related metadata for the schema where the rename took place c "DataType": "STRING", "StringMaxLength": 64, "StringEncoding": "UTF-8", - "Deprecation": true + "Deprecated": true } ] } @@ -136,7 +136,7 @@ The subsequent new schema metadata after the rename could look like this: "DataType": "STRING", "StringMaxLength": 64, "StringEncoding": "UTF-8", - "Deprecation": true + "Deprecated": true } ] } diff --git a/specification/appendix/participating_entity_identification.md b/specification/appendix/participating_entity_identification.md index 593a67c04..6a1fa1679 100644 --- a/specification/appendix/participating_entity_identification.md +++ b/specification/appendix/participating_entity_identification.md @@ -29,7 +29,7 @@ The value for each of these may vary depending on how *resources* or *services* | 3.5.1 | Purchase records for SaaS products not running on your cloud infrastructure, purchased via a reseller. Reseller does not issue payable invoices. | SaaS Provider | SaaS Provider | SaaS Provider | SaaS Provider | | 3.5.2 | Usage records for SaaS products not running on your cloud infrastructure, purchased via a reseller. Reseller does not issue payable invoices. | SaaS Provider | SaaS Provider | SaaS Provider | SaaS Provider | | 3.6.1 | Purchase records for SaaS products that have been white-labeled and sold by a reseller, not running on your cloud infrastructure. Reseller issues payable invoices. | Reseller | Reseller | Reseller | Reseller | -| 3.6.2 | Usage records for SaaS products products that have been white-labeled and sold by a reseller, not running on your cloud infrastructure. Reseller issues payable invoices. | Reseller | Reseller | Reseller | Reseller | +| 3.6.2 | Usage records for SaaS products that have been white-labeled and sold by a reseller, not running on your cloud infrastructure. Reseller issues payable invoices. | Reseller | Reseller | Reseller | Reseller | | 4.1 | Purchasing SaaS products directly from a SaaS provider, with visibility into the underlying hosting provider. | SaaS Provider | SaaS Provider | CSP | SaaS Provider | | 4.2 | Purchasing SaaS products directly from a SaaS provider, without visibility into the underlying hosting provider. | SaaS Provider | SaaS Provider | SaaS Provider | SaaS Provider | | 4.3.1 | Purchasing SaaS products running on your cloud infrastructure, purchased directly from a SaaS provider (see 4.3.2 for charges related to the underlying cloud infrastructure). | SaaS Provider | SaaS Provider | | SaaS Provider | diff --git a/specification/appendix/saas_examples/virtual_currency_pricing_model.md b/specification/appendix/saas_examples/virtual_currency_pricing_model.md index 1d288452f..ceeea207e 100644 --- a/specification/appendix/saas_examples/virtual_currency_pricing_model.md +++ b/specification/appendix/saas_examples/virtual_currency_pricing_model.md @@ -113,7 +113,7 @@ Additionally, Acme Co offers a modified usage to token ratio for one of their se Note the following details in the example dataset: * Because of the modified rate for Workflow Operations, the PricingCurrencyContractedUnitPrice and PricingCurrencyListUnitPrice are different for this charge. The ContractedUnitPrice is set to $1 and the ListUnitPrice is set to $2. -* The PricingCurrencyEffectiveCost is 240 tokens for this charge, which is less that example B2 above due to the modified rate. +* The PricingCurrencyEffectiveCost is 240 tokens for this charge, which is less than example B2 above due to the modified rate. * ListCost reflects the cost of the charge at both the list cost of the tokens and the list rate for which the usage consumes tokens. ## Scenario C: Handling Virtual Currency Usage Overages diff --git a/specification/datasets/cost_and_usage/columns/allocatedmethoddetails.md b/specification/datasets/cost_and_usage/columns/allocatedmethoddetails.md index 2be2f2513..a769edc2e 100644 --- a/specification/datasets/cost_and_usage/columns/allocatedmethoddetails.md +++ b/specification/datasets/cost_and_usage/columns/allocatedmethoddetails.md @@ -134,11 +134,11 @@ The `Elements` array contains one or more objects, each of which contains the fo } ``` -NOTE: The above JSON Type Definition (JTD) is an approximation of the expected contents of this column, but it should not be considered normative because it cannot accurately describe the normative requirements (above) for AllocatedMethodDetails. Where there are discrepancies, deference will be given to the normative requirements. For example, [NumericFormat](#numericformat) allows for multiple numeric data types and precisions, but JDT requires both to be specified; other numeric data types and precisions allowable under NumericFormat are considered valid. +NOTE: The above JSON Type Definition (JTD) is an approximation of the expected contents of this column, but it should not be considered normative because it cannot accurately describe the normative requirements (above) for AllocatedMethodDetails. Where there are discrepancies, deference will be given to the normative requirements. For example, [NumericFormat](#numericformat) allows for multiple numeric data types and precisions, but JTD requires both to be specified; other numeric data types and precisions allowable under NumericFormat are considered valid. ### Scenario 1: Single "UsageUnit" value used for allocation -When only a single "UsageUnit" is used to calculate the allaction. +When only a single "UsageUnit" is used to calculate the allocation. ```json { @@ -152,7 +152,7 @@ When only a single "UsageUnit" is used to calculate the allaction. ``` ### Scenario 2: Multiple "UsageUnit" values used for allocation -When multiple "UsageUnit" values are used to calculate the allaction, another object is added to the "Elements" collection. +When multiple "UsageUnit" values are used to calculate the allocation, another object is added to the "Elements" collection. ```json { diff --git a/specification/datasets/cost_and_usage/columns/chargeclass.md b/specification/datasets/cost_and_usage/columns/chargeclass.md index 7cd7fde95..cdaec2b54 100644 --- a/specification/datasets/cost_and_usage/columns/chargeclass.md +++ b/specification/datasets/cost_and_usage/columns/chargeclass.md @@ -1,6 +1,6 @@ # Charge Class -Charge Class indicates whether the [*row*](#glossary:row) represents a correction to a previously invoiced [*billing period*](#glossary:billing-period). Charge Class is commonly used to differentiate [*corrections](#glossary:correction) from regularly incurred [*charges*](#glossary:charge). +Charge Class indicates whether the [*row*](#glossary:row) represents a correction to a previously invoiced [*billing period*](#glossary:billing-period). Charge Class is commonly used to differentiate [*corrections*](#glossary:correction) from regularly incurred [*charges*](#glossary:charge). ## Requirements diff --git a/specification/datasets/cost_and_usage/columns/contractapplied.md b/specification/datasets/cost_and_usage/columns/contractapplied.md index 225245859..65afbc29b 100644 --- a/specification/datasets/cost_and_usage/columns/contractapplied.md +++ b/specification/datasets/cost_and_usage/columns/contractapplied.md @@ -191,7 +191,7 @@ The `Elements` array contains one or more objects, each of which contains the fo } ``` -NOTE: The above JSON Type Definition (JTD) is an approximation of the expected contents of this column, but it should not be considered normative because it cannot accurately describe the normative requirements (above) for ContractApplied. Where there are discrepancies, deference will be given to the normative requirements. For example, [NumericFormat](#numericformat) allows for multiple numeric data types and precisions, but JDT requires both to be specified; other numeric data types and precisions allowable under NumericFormat are considered valid. +NOTE: The above JSON Type Definition (JTD) is an approximation of the expected contents of this column, but it should not be considered normative because it cannot accurately describe the normative requirements (above) for ContractApplied. Where there are discrepancies, deference will be given to the normative requirements. For example, [NumericFormat](#numericformat) allows for multiple numeric data types and precisions, but JTD requires both to be specified; other numeric data types and precisions allowable under NumericFormat are considered valid. ## Example Scenarios diff --git a/specification/datasets/cost_and_usage/columns/invoiceid.md b/specification/datasets/cost_and_usage/columns/invoiceid.md index ddeec6dc9..92478d1b7 100644 --- a/specification/datasets/cost_and_usage/columns/invoiceid.md +++ b/specification/datasets/cost_and_usage/columns/invoiceid.md @@ -1,6 +1,6 @@ # Invoice ID -An Invoice ID is a invoice-issuer-assigned identifier for an invoice encapsulating [*charges*](#glossary:charge) in the corresponding [*billing period*](#glossary:billing-period) for a given [*billing account*](#glossary:billing-account). Invoices are commonly used for scenarios like tracking billing transactions, facilitating payment processes and for performing invoice reconciliation between *charges* and billing periods. +An Invoice ID is an invoice-issuer-assigned identifier for an invoice encapsulating [*charges*](#glossary:charge) in the corresponding [*billing period*](#glossary:billing-period) for a given [*billing account*](#glossary:billing-account). Invoices are commonly used for scenarios like tracking billing transactions, facilitating payment processes and for performing invoice reconciliation between *charges* and billing periods. ## Requirements diff --git a/specification/datasets/cost_and_usage/columns/tags.md b/specification/datasets/cost_and_usage/columns/tags.md index 8433aeb03..c143ecd9f 100644 --- a/specification/datasets/cost_and_usage/columns/tags.md +++ b/specification/datasets/cost_and_usage/columns/tags.md @@ -45,7 +45,7 @@ The last two tags illustrate examples from two different, provider-defined tag s ## Finalized Tags -Within a data generator, tag keys may be associated with multiple values, and potentially defined at different levels within the data generator, such as accounts, folders, [*resource*](#glossary:resource) and other *resource* grouping constructs. When finalizing, *data generator* must reduce these multiple levels of definition to a single value where each key is associated with exactly one value. The method by which this is done and the semantics are up to each data generatorder but must be documented within their respective documentation. +Within a data generator, tag keys may be associated with multiple values, and potentially defined at different levels within the data generator, such as accounts, folders, [*resource*](#glossary:resource) and other *resource* grouping constructs. When finalizing, *data generator* must reduce these multiple levels of definition to a single value where each key is associated with exactly one value. The method by which this is done and the semantics are up to each data generator but must be documented within their respective documentation. As an example, let's assume 1 [*sub account*](#glossary:sub-account) exists with 1 virtual machine with the following details, and tag inheritance favors Resources over *Sub Accounts*. diff --git a/specification/metadata/metadata_overview.md b/specification/metadata/metadata_overview.md index 124a437ad..35b3e1e4f 100644 --- a/specification/metadata/metadata_overview.md +++ b/specification/metadata/metadata_overview.md @@ -1,6 +1,6 @@ # Metadata -The FOCUS specification defines a metadata structure to be supplied by data providers to facilitate practitioners' use of FOCUS data. This metadata includes general information the [*dataset artifact*](#glossary:dataset-artifact). +The FOCUS specification defines a metadata structure to be supplied by data providers to facilitate practitioners' use of FOCUS data. This metadata includes general information about the [*dataset artifact*](#glossary:dataset-artifact). The metadata includes the following sections: diff --git a/specification/metadata/recency/dataset_instance_complete.md b/specification/metadata/recency/dataset_instance_complete.md index 70ddfebda..135473a3d 100644 --- a/specification/metadata/recency/dataset_instance_complete.md +++ b/specification/metadata/recency/dataset_instance_complete.md @@ -4,7 +4,7 @@ Dataset Instance Complete provides a boolean value to indicate that the dataset DatasetInstanceComplete adheres to the following requirements: -* DatasetInstanceComplete MUST be present in an object within the [Recency](#recency) collection when the the dataset instance is not a time-series dataset. +* DatasetInstanceComplete MUST be present in an object within the [Recency](#recency) collection when the dataset instance is not a time-series dataset. * DatasetInstanceComplete MUST be of type Boolean. * DatasetInstanceComplete MUST NOT be null. diff --git a/specification/metadata/recency/time_sectors/time_sectors_overview.md b/specification/metadata/recency/time_sectors/time_sectors_overview.md index 87081969a..3b2614c30 100644 --- a/specification/metadata/recency/time_sectors/time_sectors_overview.md +++ b/specification/metadata/recency/time_sectors/time_sectors_overview.md @@ -6,7 +6,7 @@ The FOCUS recency metadata's Time Sectors provide a list of time periods and met TimeSectors adheres to the following requirements: -* TimeSectors MUST be present in an object within the [Recency](#recency) collection when the the associated *FOCUS dataset* is defined as a time series dataset. +* TimeSectors MUST be present in an object within the [Recency](#recency) collection when the associated *FOCUS dataset* is defined as a time series dataset. * TimeSectors MUST be structured as a collection of objects. * TimeSectors MUST NOT be null. * TimeSectors collection MUST contain at least one object. diff --git a/specification/overview.md b/specification/overview.md index a5033a7f2..a0c81fd9b 100644 --- a/specification/overview.md +++ b/specification/overview.md @@ -94,7 +94,7 @@ Under each column defined in the FOCUS specification, there exists a 'Feature le Validation tools may be employed to determine conformance of data and implementations per this specification. -The FinOps Foundation maintains a validator called the [FOCUS Validator](https://github.com/finopsfoundation/focus_validator) which it uses for its own conformance assessments and as serves as a reference implementation to support validation activities. +The FinOps Foundation maintains a validator called the [FOCUS Validator](https://github.com/finopsfoundation/focus_validator) which it uses for its own conformance assessments and serves as a reference implementation to support validation activities. Other validation tools may be developed and made available by third parties. The FOCUS specification does not mandate the use of any particular tool, nor does it maintain a registry of available validators. diff --git a/specification/spec_abstract.md b/specification/spec_abstract.md index 99d9026aa..11cd3ccae 100644 --- a/specification/spec_abstract.md +++ b/specification/spec_abstract.md @@ -1 +1 @@ -FOCUS is an open specification for billing data. It defines a common schema for billing data, aligns terminology with the FinOps Framework and defines a minimum set of requirements for billing data. The specification provides clear guideline for billing data generators to produce FinOps-serviceable data. The specification enables FinOps practitioners to perform common FinOps capabilities such as chargeback, cost allocation, budgeting and forecasting etc. using a generic set of instructions, regardless of the origin of the FOCUS compatible dataset. +FOCUS is an open specification for billing data. It defines a common schema for billing data, aligns terminology with the FinOps Framework and defines a minimum set of requirements for billing data. The specification provides clear guidelines for billing data generators to produce FinOps-serviceable data. The specification enables FinOps practitioners to perform common FinOps capabilities such as chargeback, cost allocation, budgeting and forecasting etc. using a generic set of instructions, regardless of the origin of the FOCUS compatible dataset. diff --git a/specification/supported_features/contract_commitments.md b/specification/supported_features/contract_commitments.md index b1519209b..4996db137 100644 --- a/specification/supported_features/contract_commitments.md +++ b/specification/supported_features/contract_commitments.md @@ -2,7 +2,7 @@ ## Description -FOCUS supports the tracking of commitments made via contractual agreements between a service provider and a customer. Each row in the Cost and Usage dataset is associated with one or more unique identifiers representing those contracts and contract commitments, stored in a JSON column called Contract Applied. A richer amount of detail that describes those commitments is carried in a separate Contract Commitment dataset, which can be joined to the Cost and Usage datset to facilitate various queries involving filtering and aggregation. +FOCUS supports the tracking of commitments made via contractual agreements between a service provider and a customer. Each row in the Cost and Usage dataset is associated with one or more unique identifiers representing those contracts and contract commitments, stored in a JSON column called Contract Applied. A richer amount of detail that describes those commitments is carried in a separate Contract Commitment dataset, which can be joined to the Cost and Usage dataset to facilitate various queries involving filtering and aggregation. The Contract Applied column contains several FOCUS-defined properties. For more information, see the definition of Contract Applied [here](#contractapplied). diff --git a/specification/supported_features/cost_and_usage_attribution.md b/specification/supported_features/cost_and_usage_attribution.md index 9d772a864..cfc471141 100644 --- a/specification/supported_features/cost_and_usage_attribution.md +++ b/specification/supported_features/cost_and_usage_attribution.md @@ -2,7 +2,7 @@ ## Description -Many service providers have features that allow Finops practitioners to enrich cost and usage data with metadata, that is addition to service provider defined data, in order to analyze Finops data using organizational, deployment, or other structures. These features may take the form of directly applied metadata or inherited metadata. FOCUS facilitates the inclusion of this metadata at a row level. +Many service providers have features that allow FinOps practitioners to enrich cost and usage data with metadata that is in addition to service provider defined data, in order to analyze FinOps data using organizational, deployment, or other structures. These features may take the form of directly applied metadata or inherited metadata. FOCUS facilitates the inclusion of this metadata at a row level. ## Directly Dependent Columns diff --git a/supporting_content/datasets/cost_and_usage/columns/chargefrequency.md b/supporting_content/datasets/cost_and_usage/columns/chargefrequency.md index e0f7ec1bd..7786065c2 100644 --- a/supporting_content/datasets/cost_and_usage/columns/chargefrequency.md +++ b/supporting_content/datasets/cost_and_usage/columns/chargefrequency.md @@ -22,7 +22,7 @@ Current values observed in billing data for various scenarios: ## Example Usecases -- Finops team identify and handle large one-time purchases to avoid (or educate on) large scary spikes in cloud monitoring tools/platforms. +- FinOps team identify and handle large one-time purchases to avoid (or educate on) large scary spikes in cloud monitoring tools/platforms. - Finance teams identify and allocate one-time purchases either by amortization or cost recovery from the right entity. - Engineering managers are able to identify usage-based charges to include in their budget or forecasting processes. diff --git a/supporting_content/datasets/cost_and_usage/columns/invoiceid.md b/supporting_content/datasets/cost_and_usage/columns/invoiceid.md index dfed1d656..7a81ffffc 100644 --- a/supporting_content/datasets/cost_and_usage/columns/invoiceid.md +++ b/supporting_content/datasets/cost_and_usage/columns/invoiceid.md @@ -34,7 +34,7 @@ Examples of this can eb found here: https://docs.google.com/spreadsheets/d/1fzLu # Provider information on invoice handling ## Google Invoices do not contain any row level details or product details; they only contain a link to the cost table in the billing console which is linked to the invoice.month column. -Invoices may show different totals to finops dashboards as an invoice month may be calculated differently to a calendar month, practitioner would need to understand this difference and how to map the data in Finops reports to calendar month and invoice month, they would require a report in their finops reporting tools that showed the detailed report for invoice month and calendar month: https://cloud.google.com/billing/docs/how-to/cost-table. +Invoices may show different totals to finops dashboards as an invoice month may be calculated differently to a calendar month, practitioner would need to understand this difference and how to map the data in FinOps reports to calendar month and invoice month, they would require a report in their finops reporting tools that showed the detailed report for invoice month and calendar month: https://cloud.google.com/billing/docs/how-to/cost-table. Google invoices are issued on the last day of the month and contain a document number which is the invoice ID. Depending on your google structure you have one primary billing accounts and invoices would be issued against the primary billing account ID. Generally, non service provider cloud users will have one billing account, SaaS providers or service providers may have sub billing account id's to separate out charges for customers but are all rolled up to the primary billing account id. ## Microsoft diff --git a/supporting_content/metadata/metadata_requirements_overview.md b/supporting_content/metadata/metadata_requirements_overview.md index 21932a45c..fa7dd809b 100644 --- a/supporting_content/metadata/metadata_requirements_overview.md +++ b/supporting_content/metadata/metadata_requirements_overview.md @@ -127,7 +127,7 @@ Recency adheres to the following requirements: TimeSectors adheres to the following requirements: -* TimeSectors MUST be present in an object within the [Recency](#recency) collection when the the associated *FOCUS dataset* is defined as a time series dataset. +* TimeSectors MUST be present in an object within the [Recency](#recency) collection when the associated *FOCUS dataset* is defined as a time series dataset. * TimeSectors MUST be structured as a collection of objects. * TimeSectors MUST NOT be null. * TimeSectors collection MUST contain at least one object.