diff --git a/lib/README.md b/lib/README.md index b3e17375..fed54267 100644 --- a/lib/README.md +++ b/lib/README.md @@ -13,7 +13,8 @@ This folder contains several Node.js modules that generate OASIS specification d See [subsection ##SubsectionHeading]. Reference to a subsection showing its number. See [this example](#aggregation). Reference to an example. See [example ##aggregation]. Reference to an example showing its number. - See [OData-Protocol, section #odata-protocol#SectionHeading]. Cross-document reference. + See [#OData-Protocol#SectionHeading]. Cross-document section reference. + See [OData-Protocol, example #OData-Protocol#SectionHeading]. Other cross-document reference. [This important sentence]{id=important} is referenced [elsewhere](#important). ``` - Lines ending with single space are joined with the next line. diff --git a/lib/iterator.js b/lib/iterator.js index f16b3ffb..b39a2947 100644 --- a/lib/iterator.js +++ b/lib/iterator.js @@ -13,11 +13,9 @@ module.exports = function (callback) { const meta = yaml.load( fs.readFileSync(`${__dirname}/../${doc.name}/${metaname}`), ); - meta.name = - metaname === "meta.yaml" || !meta.dirname ? doc.name : meta.dirname; callback( doc.name, - meta.name, + metaname === "meta.yaml" || !meta.dirname ? doc.name : meta.dirname, metaname.substring(0, metaname.length - 5), { ...metameta, diff --git a/lib/number.js b/lib/number.js index bc972e2e..32c90b0f 100644 --- a/lib/number.js +++ b/lib/number.js @@ -211,18 +211,22 @@ class Number { } out.write( outline.replace( - /#([-A-Za-z0-9]*)#([A-Za-z0-9.]+)\]/g, - function (m, d, p) { + /(\[?)#([-A-Za-z0-9]*)#([A-Za-z0-9.]+)\]/g, + function (m, o, d, p) { var f, r; - if (d && this.meta[d]) f = this.meta[d] + "#"; - else if (!d) f = "#"; - if (f) r = (d ? builders[d] : this)?.refs[p]; - if (r) return `${r}](${f}${p})`; + if (d && (r = builders[d]?.refs[p])) { + if (o) r = `${d}, section ${r}`; + f = builders[d].meta.url; + } else if (!d) { + r = this.refs[p]; + f = ""; + } + if (r) return `${o}${r}](${f}#${p})`; else { this.errors.push( - `${d || this.dir}/${file}(${lineno}): Undefined link #${d}#${p}`, + `${this.dir}/${file}(${lineno}): Undefined link #${d}#${p}`, ); - return `~~${d}#${p}~~]`; + return `${o}~~${d}#${p}~~]`; } }.bind(this), ), diff --git a/lib/server.js b/lib/server.js index 82c9adea..e2c6a25c 100644 --- a/lib/server.js +++ b/lib/server.js @@ -47,7 +47,7 @@ const app = express() var number = new Number( `${__dirname}/../${req.params.doc}`, req.query.variant, - { ...metameta, ...meta, name: meta.dirname || req.params.doc }, + { ...metameta, ...meta }, ); delete req.query.variant; res.type("html"); diff --git a/meta.yaml b/meta.yaml index 6c065eac..b6dc4acc 100644 --- a/meta.yaml +++ b/meta.yaml @@ -1,10 +1,3 @@ -odata-csdl-json: https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/odata-csdl-json-v4.02.html -odata-csdl-xml: https://docs.oasis-open.org/odata/odata-csdl-xml/v4.02/odata-csdl-xml-v4.02.html -odata-json-format: https://docs.oasis-open.org/odata/odata-json-format/v4.02/odata-json-format-v4.02.html -odata-data-aggregation-ext: https://docs.oasis-open.org/odata/odata-data-aggregation-ext/v4.0/odata-data-aggregation-ext-v4.0.html -odata-temporal-ext: https://docs.oasis-open.org/odata/odata-temporal-ext/v4.0/odata-temporal-ext-v4.0.html -odata-protocol: https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html -odata-url-conventions: https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html OData-VocCore: https://github.com/oasis-tcs/odata-vocabularies/blob/main/vocabularies/Org.OData.Core.V1.md OData-VocCap: https://github.com/oasis-tcs/odata-vocabularies/blob/main/vocabularies/Org.OData.Capabilities.V1.md OData-VocAggr: https://github.com/oasis-tcs/odata-vocabularies/blob/main/vocabularies/Org.OData.Aggregation.V1.md \ No newline at end of file diff --git a/odata-csdl/12 Action and Function.md b/odata-csdl/12 Action and Function.md index 319fe4d7..99c0b3ac 100644 --- a/odata-csdl/12 Action and Function.md +++ b/odata-csdl/12 Action and Function.md @@ -162,7 +162,7 @@ Unbound actions are invoked from the entity container through an [action import](#ActionImport). Unbound functions are invoked as static functions within a common expression -(see [OData-URL, section #odata-url-conventions#CommonExpressionSyntax]), +(see [#OData-URL#CommonExpressionSyntax]), or from the entity container through a [function import](#FunctionImport). ::: {.varjson .rep} diff --git a/odata-csdl/14 Vocabulary and Annotation.md b/odata-csdl/14 Vocabulary and Annotation.md index 0b40978c..e2002b22 100644 --- a/odata-csdl/14 Vocabulary and Annotation.md +++ b/odata-csdl/14 Vocabulary and Annotation.md @@ -2571,7 +2571,7 @@ Name property of the Actor entity The `odata.matchesPattern` client-side function takes two string expressions as arguments and returns a Boolean value. -It is the counterpart of the identically named URL function [OData-URL, section #odata-url-conventions#matchespattern]. +It is the counterpart of the identically named URL function [#OData-URL#matchespattern]. The function returns true if the second expression evaluates to an [ECMAScript](#_ECMAScript) (JavaScript) regular expression and diff --git a/odata-csdl/json.yaml b/odata-csdl/json.yaml index 0bcc584b..fd3b8f6b 100644 --- a/odata-csdl/json.yaml +++ b/odata-csdl/json.yaml @@ -1,3 +1,5 @@ +name: OData-CSDL +url: https://docs.oasis-open.org/odata/odata-csdl-json/v4.02/odata-csdl-json-v4.02.html pagetitle: OData Common Schema Definition Language (CSDL) JSON Representation Version 4.02 subtitle: Committee Specification Draft 02 dirname: odata-csdl-json diff --git a/odata-csdl/xml.yaml b/odata-csdl/xml.yaml index 5bff1a54..7a3f06b0 100644 --- a/odata-csdl/xml.yaml +++ b/odata-csdl/xml.yaml @@ -1,3 +1,5 @@ +name: OData-CSDLXML +url: https://docs.oasis-open.org/odata/odata-csdl-xml/v4.02/odata-csdl-xml-v4.02.html pagetitle: OData Common Schema Definition Language (CSDL) XML Representation Version 4.02 subtitle: Committee Specification Draft 02 dirname: odata-csdl-xml diff --git a/odata-data-aggregation-ext/3.1 Fundamentals of Input and Output Sets.md b/odata-data-aggregation-ext/3.1 Fundamentals of Input and Output Sets.md index ca22ead8..03598011 100644 --- a/odata-data-aggregation-ext/3.1 Fundamentals of Input and Output Sets.md +++ b/odata-data-aggregation-ext/3.1 Fundamentals of Input and Output Sets.md @@ -7,7 +7,7 @@ A _set transformation_ (_transformation_ for short) is an operation on an input The system query option `$apply` MUST NOT be used if the resource path addresses a single instance. -The system query option `$apply` is evaluated first, then the other system query options are evaluated, if applicable, on the result of `$apply`, see [OData-Protocol, section #odata-protocol#SystemQueryOptions]. Stability across requests for system query options `$top` and `$skip` [OData-Protocol, sections "System Query Option `$top`" and "System Query Option `$skip`"]($$$OData-Protocol$$$#SystemQueryOptiontop) is defined in [section ##StableTotalOrderBeforeskipandtop]. +The system query option `$apply` is evaluated first, then the other system query options are evaluated, if applicable, on the result of `$apply`, see [#OData-Protocol#SystemQueryOptions]. Stability across requests for system query options `$top` and `$skip` [OData-Protocol, sections "System Query Option `$top`" and "System Query Option `$skip`"]($$$OData-Protocol$$$#SystemQueryOptiontop) is defined in [section ##StableTotalOrderBeforeskipandtop]. Each set transformation: - carries over the input type to the output set such that it fits into the data model of the service. @@ -33,13 +33,13 @@ The definitions of italicized terms made in this section are used throughout thi ### ##subsubsec Type, Structure and Context URL -All input sets and output sets in one transformation sequence are collections of the _input type_, that is the entity type or complex type of the first input set, or in other words, of the resource to which the transformation sequence is applied. The input type is determined by the entity model element identified within the metadata document by the context URL of that resource [OData-Protocol, section #odata-protocol#ContextURL]. Individual instances in an input or output set can have a subtype of the input type. (See [example ##subinputtype].) The transformation sequence given as the `$apply` system query option is applied to the resource addressed by the resource path. The transformations defined below can have nested transformation sequences as parameters, these are then applied to resources that can differ from the current input set. +All input sets and output sets in one transformation sequence are collections of the _input type_, that is the entity type or complex type of the first input set, or in other words, of the resource to which the transformation sequence is applied. The input type is determined by the entity model element identified within the metadata document by the context URL of that resource [#OData-Protocol#ContextURL]. Individual instances in an input or output set can have a subtype of the input type. (See [example ##subinputtype].) The transformation sequence given as the `$apply` system query option is applied to the resource addressed by the resource path. The transformations defined below can have nested transformation sequences as parameters, these are then applied to resources that can differ from the current input set. The _structure_ of an instance that occurs in an input or output set is defined by the names of the structural and navigation properties that the instance contains. Instances of an input type can have different structures, subject to the following rules: - Declared properties of the input type or a nested or related type thereof or of a subtype of one of these MUST have their declared type and meaning when they occur in an input or output set. - Single- or collection-valued primitive properties addressed by a property path starting at a non-transient entity MUST keep their values from the addressed resource path collection throughout the transformation sequence. Likewise, single- or collection-valued navigation property paths starting at a non-transient entity MUST keep addressing the same non-transient entities as in the addressed resource path collection. - Instances in an output set need not have all declared or dynamic properties that occurred in the input set. -- Instances in an output set can have dynamic properties that did not occur in the input set. The name for such a dynamic property is called an _alias_, it is a simple identifier (see [OData-CSDL, section #odata-csdl-json#SimpleIdentifier]). Aliases MUST differ from names of declared properties in the input type, from names of properties in the first input set, and from names of properties in the current input set. Aliases in one collection MUST also differ from each other. +- Instances in an output set can have dynamic properties that did not occur in the input set. The name for such a dynamic property is called an _alias_, it is a simple identifier (see [#OData-CSDL#SimpleIdentifier]). Aliases MUST differ from names of declared properties in the input type, from names of properties in the first input set, and from names of properties in the current input set. Aliases in one collection MUST also differ from each other. Here is an overview of the structural changes made by different transformations: - During [aggregation](#BasicAggregation) or [nest](#Transformationnest), many instances are replaced by one instance, properties that represent the aggregation level are retained, and others are replaced by dynamic properties holding the aggregate value of the many instances or a transformed copy of them. @@ -48,15 +48,15 @@ Here is an overview of the structural changes made by different transformations: - During [join](#Transformationsjoinandouterjoin), one instance with a collection of related instances is replaced by many copies, each of which is related via a dynamic property to one of the related instances. - During [concatenation](#Transformationconcat), the same instances are transformed multiple times and the output sets with their potentially different structures are concatenated. -An output set thus consists of instances with different structures. This is the same situation as with a collection of an open type ([OData-CSDL, section #odata-csdl-json#OpenEntityType] and [OData-CSDL, section #odata-csdl-json#OpenComplexType]) and it is handled in the same way. +An output set thus consists of instances with different structures. This is the same situation as with a collection of an open type ([#OData-CSDL#OpenEntityType] and [#OData-CSDL#OpenComplexType]) and it is handled in the same way. -If the first input set is a collection of entities from a given entity set, then so are all input sets and output sets in the transformation sequence. The `{select-list}` in the context URL [OData-Protocol, section #odata-protocol#ContextURL] MUST describe only properties that are present or annotated as absent (for example, if `Core.Permissions` is `None` [OData-Protocol, section #odata-protocol#RequestingIndividualEntities]) in all instances of the collection, after applying any `$select` and `$expand` system query options. The `{select-list}` SHOULD describe as many such properties as possible, even if the request involves a concatenation that leads to a non-homogeneous structure. If the server cannot determine any such properties, the `{select-list}` MUST consist of just the instance annotation `AnyStructure` defined in the [`Core` vocabulary]($$$OData-VocCore$$$#AnyStructure). (See [example ##anystructure].) +If the first input set is a collection of entities from a given entity set, then so are all input sets and output sets in the transformation sequence. The `{select-list}` in the context URL [#OData-Protocol#ContextURL] MUST describe only properties that are present or annotated as absent (for example, if `Core.Permissions` is `None` [#OData-Protocol#RequestingIndividualEntities]) in all instances of the collection, after applying any `$select` and `$expand` system query options. The `{select-list}` SHOULD describe as many such properties as possible, even if the request involves a concatenation that leads to a non-homogeneous structure. If the server cannot determine any such properties, the `{select-list}` MUST consist of just the instance annotation `AnyStructure` defined in the [`Core` vocabulary]($$$OData-VocCore$$$#AnyStructure). (See [example ##anystructure].) ### ##subsubsec Sameness and Order Input sets and output sets are not sets of instances in the mathematical sense but collections, because the same instance can occur multiple times in them. In other words: A collection contains values (which can be instances of structured types or primitive values), possibly with repetitions. The occurrences of the values in the collection form a set in the mathematical sense. The _cardinality_ of a collection is the total number of occurrences in it. When this text describes a transformation algorithmically and stipulates that certain steps are carried out _for each occurrence_ in a collection, this means that the steps are carried out multiple times for the same value if it occurs multiple times in the collection. -A collection addressed by the resource path is returned by the service either as an ordered collection [OData-Protocol, section #odata-protocol#ManagingMembersofanOrderedCollection] or as an unordered collection. The same applies to collections that are nested in or related to the addressed resource as well as to collections that are the result of evaluating an expression starting with `$root`, which occur, for example, as the first parameter of a [hierarchical transformation](#HierarchicalTransformations). +A collection addressed by the resource path is returned by the service either as an ordered collection [#OData-Protocol#ManagingMembersofanOrderedCollection] or as an unordered collection. The same applies to collections that are nested in or related to the addressed resource as well as to collections that are the result of evaluating an expression starting with `$root`, which occur, for example, as the first parameter of a [hierarchical transformation](#HierarchicalTransformations). But when such a collection is transformed by the `$apply` system query option, additional cases can arise that are neither ordered nor totally unordered. For example, the [`groupby`](#Transformationgroupby) transformation retains any order within a group but not between groups. @@ -79,10 +79,10 @@ A collection can be _stable-sorted_ by a list of expressions. In the stable-sort Stable-sorting of an ordered collection produces another ordered collection. A stable-sort does not necessarily produce a total order, the sorted collection may still contain two occurrences whose relative order does not matter. The transformation [`orderby`](#Transformationorderby) performs a stable-sort. -The output set of a [basic aggregation](#BasicAggregation) transformation can contain instances of an entity type without entity-id. After a [`concat`](#Transformationconcat) transformation, different occurrences of the same entity can differ in individual non-declared properties. To account for such cases, the definition of sameness given in [OData-URL, section #odata-url-conventions#Equals] is refined here. Instances of structured types are _the same_ if +The output set of a [basic aggregation](#BasicAggregation) transformation can contain instances of an entity type without entity-id. After a [`concat`](#Transformationconcat) transformation, different occurrences of the same entity can differ in individual non-declared properties. To account for such cases, the definition of sameness given in [#OData-URL#Equals] is refined here. Instances of structured types are _the same_ if - both are instances of complex types and both are null or both have the same structure and same values with null considered different from absent or -- both are instances of entity types without entity-id (see [OData-Protocol, section #odata-protocol#TransientEntities]) and both are null or both have the same structure and same values with null considered different from absent (informally speaking, they are compared like complex instances) or -- (1) both are instances of the same entity type with the same entity-id (non-transient entities, see [OData-Protocol, section #odata-protocol#EntityIdsandEntityReferences]) and (2) the structural and navigation properties contained in both have the same values (for non-primitive properties the sameness of values is decided by a recursive invocation of this definition). +- both are instances of entity types without entity-id (see [#OData-Protocol#TransientEntities]) and both are null or both have the same structure and same values with null considered different from absent (informally speaking, they are compared like complex instances) or +- (1) both are instances of the same entity type with the same entity-id (non-transient entities, see [#OData-Protocol#EntityIdsandEntityReferences]) and (2) the structural and navigation properties contained in both have the same values (for non-primitive properties the sameness of values is decided by a recursive invocation of this definition). - If this is fulfilled, the instances are called _complementary representations of the same non-transient entity_. If this case is encountered at some recursion level while the sameness of non-transient entities $u_1$ and $u_2$ is established, a merged representation of the entity $u_1=u_2$ exists that contains all properties of $u_1$ and $u_2$. But if the instances both occur in the last output set, services MUST represent each with its own structure in the response payload. - If the first condition is fulfilled but not the second, the instances are not the same and are called _contradictory representations of the same non-transient entity_. ([Example ##contradict] describes a use case for this.) @@ -94,13 +94,13 @@ Collections are _the same_ if there is a one-to-one correspondence $f$ between t This document specifies how a [data aggregation path](#DataAggregationPath) that occurs in a request is evaluated by the service. If such an evaluation fails, the service MUST reject the request. -For a data aggregation path to be a common expression according to [OData-URL, section #odata-url-conventions#CommonExpressionSyntax], its segments must be single-valued with the possible exception of the last segment, and it can then be evaluated relative to an instance of a structured type. For the transformations defined in this document, a data aggregation path can also be evaluated relative to a collection $A$, even if it has arbitrary collection-valued segments itself. +For a data aggregation path to be a common expression according to [#OData-URL#CommonExpressionSyntax], its segments must be single-valued with the possible exception of the last segment, and it can then be evaluated relative to an instance of a structured type. For the transformations defined in this document, a data aggregation path can also be evaluated relative to a collection $A$, even if it has arbitrary collection-valued segments itself. To this end, the following notation is used in the subsequent sections: If $A$ is a collection and $p$ a data aggregation path, optionally followed by a type-cast segment, the result of such a path evaluation is denoted by $\Gamma(A,p)$ and defined as the unordered concatenation, possibly containing repetitions, of the collections $γ(u,p)$ for each $u$ in $A$ that is not null. The function $γ(u,p)$ takes a non-null value and a path as arguments and returns a collection of instances of structured types or primitive values, depending on the type of the final segment of $p$. It is recursively defined as follows: 1. If $p$ is an empty path, let $B$ be a collection with $u$ as its single member and continue with step 9. 2. Let $p_1$ be the first segment of $p$ and $p_2$ the remainder, if any, such that $p$ equals the concatenated path $p_1/p_2$. 3. If $p_1$ is a type-cast segment and $u$ is of its type or a subtype thereof, let $v=u$ and continue with step 8. -4. If $p_1$ is a type-cast segment and $u$ is not of its type or a subtype thereof, let $B$ be an empty collection and continue with step 9. (This rule follows [OData-URL, section #odata-url-conventions#AddressingDerivedTypes] rather than [OData-CSDL, section #odata-csdl-json#PathSyntax].) +4. If $p_1$ is a type-cast segment and $u$ is not of its type or a subtype thereof, let $B$ be an empty collection and continue with step 9. (This rule follows [#OData-URL#AddressingDerivedTypes] rather than [#OData-CSDL#PathSyntax].) 5. Otherwise, $p_1$ is a non-type-cast segment. If $u$ does not contain a structural or navigation property $p_1$, let $B$ be an empty collection and continue with step 9. 6. If $p_1$ is single-valued, let $v$ be the value of the structural or navigation property $p_1$ in $u$. If $v$ is null, let $B$ be an empty collection and continue with step 9; otherwise continue with step 8. 7. Otherwise, $p_1$ is collection-valued. Let $C$ be the collection addressed by the structural or navigation property $p_1$ in $u$, and let $B=\Gamma(C,p_2)$. Then continue with step 9. diff --git a/odata-data-aggregation-ext/3.2 Basic Aggregation.md b/odata-data-aggregation-ext/3.2 Basic Aggregation.md index 47680235..0fbc63be 100644 --- a/odata-data-aggregation-ext/3.2 Basic Aggregation.md +++ b/odata-data-aggregation-ext/3.2 Basic Aggregation.md @@ -165,7 +165,7 @@ results in ##### ##subsubsubsubsec Standard Aggregation Method `countdistinct` -The aggregation method `countdistinct` can be applied to arbitrary collections to count the distinct values. Instance comparison uses the definition of equality in [OData-URL, section #odata-url-conventions#Equals]. +The aggregation method `countdistinct` can be applied to arbitrary collections to count the distinct values. Instance comparison uses the definition of equality in [#OData-URL#Equals]. The result property MUST have type `Edm.Decimal` with `Scale` 0 and sufficient `Precision`. diff --git a/odata-data-aggregation-ext/3.4 Transformations Changing the Input Set Structure.md b/odata-data-aggregation-ext/3.4 Transformations Changing the Input Set Structure.md index 4f279968..8468b630 100644 --- a/odata-data-aggregation-ext/3.4 Transformations Changing the Input Set Structure.md +++ b/odata-data-aggregation-ext/3.4 Transformations Changing the Input Set Structure.md @@ -19,7 +19,7 @@ The `compute` transformation takes a comma-separated list of one or more _comput A compute expression is a common expression followed by the `as` keyword, followed by an [alias](#TypeStructureandContextURL). -The output set is constructed by copying the instances of the input set and adding one dynamic property per compute expression to [each occurrence](#SamenessandOrder) in the output set. The name of each added dynamic property is the alias of the corresponding compute expression. The value of each added dynamic property is computed relative to the corresponding instance. Services MAY support expressions that address dynamic properties added by other expressions within the same `compute` transformation, provided that the service can determine an evaluation sequence. The type of the property is determined by the rules for evaluating common expressions and numeric promotion defined in [OData-URL, section #odata-url-conventions#CommonExpressionSyntax]. +The output set is constructed by copying the instances of the input set and adding one dynamic property per compute expression to [each occurrence](#SamenessandOrder) in the output set. The name of each added dynamic property is the alias of the corresponding compute expression. The value of each added dynamic property is computed relative to the corresponding instance. Services MAY support expressions that address dynamic properties added by other expressions within the same `compute` transformation, provided that the service can determine an evaluation sequence. The type of the property is determined by the rules for evaluating common expressions and numeric promotion defined in [#OData-URL#CommonExpressionSyntax]. ::: example Example ##ex: @@ -48,7 +48,7 @@ results in The `addnested` transformation expands a path relative to the input set, applies one or more transformation sequences to the addressed resources, and adds the transformed resources as dynamic (navigation) properties to the output set. The output set $A$ is initially a clone of the input set. -The first parameter of the `addnested` transformation is a path $p$ or a concatenated path $p/q$. Here, $p=p_1/…/p_k$ with $k≥1$ is a [data aggregation path](#DataAggregationPath) with single- or collection-valued segments. The path $p$ MUST NOT contain any navigation properties prior to the last segment $p_k$, which MUST either be a navigation or a complex structural property. If the optional $q$ is present, it MUST be a type-cast segment. This is an extension of the definition in [OData-URL, section #odata-url-conventions#SystemQueryOptionexpand] in that the first parameter need not contain a navigation property. +The first parameter of the `addnested` transformation is a path $p$ or a concatenated path $p/q$. Here, $p=p_1/…/p_k$ with $k≥1$ is a [data aggregation path](#DataAggregationPath) with single- or collection-valued segments. The path $p$ MUST NOT contain any navigation properties prior to the last segment $p_k$, which MUST either be a navigation or a complex structural property. If the optional $q$ is present, it MUST be a type-cast segment. This is an extension of the definition in [#OData-URL#SystemQueryOptionexpand] in that the first parameter need not contain a navigation property. Further parameters are one or more transformation sequences followed by the `as` keyword followed by an [alias](#TypeStructureandContextURL) whose name need not differ from names in the input set but MUST differ from names already in $\Gamma(A,p_1/…/p_{k-1})$ (using the [$\Gamma$ notation](#EvaluationofDataAggregationPaths)) as well as from aliases for other transformation sequences. diff --git a/odata-data-aggregation-ext/3.6 Expressions Evaluable on a Collection.md b/odata-data-aggregation-ext/3.6 Expressions Evaluable on a Collection.md index 117af624..6dfc317c 100644 --- a/odata-data-aggregation-ext/3.6 Expressions Evaluable on a Collection.md +++ b/odata-data-aggregation-ext/3.6 Expressions Evaluable on a Collection.md @@ -3,10 +3,10 @@ The following two subsections introduce two new types of [expression](#Expression) that are evaluated relative to a collection, called the input collection. These expressions are -- either prepended with a collection-valued path $p$ followed by a forward slash, like a lambda operator [OData-URL, section #odata-url-conventions#LambdaOperators]. The collection identified by that path is then the input collection for the expression. +- either prepended with a collection-valued path $p$ followed by a forward slash, like a lambda operator [#OData-URL#LambdaOperators]. The collection identified by that path is then the input collection for the expression. - or prepended with the keyword `$these` followed by a forward slash, the input collection is then the _current collection_ defined as follows: - In a system query option other than `$apply`, possibly nested within `$expand` or `$select`, the current collection is the collection that is the subject of the system query option. - - In a path segment that addresses a subset of a collection [OData-URL, section #odata-url-conventions#AddressingaSubsetofaCollection], the current collection is the collection that is the subject of the path segment. + - In a path segment that addresses a subset of a collection [#OData-URL#AddressingaSubsetofaCollection], the current collection is the collection that is the subject of the path segment. - In an `$apply` transformation, the current collection is the input set of the transformation. ### ##subsubsec Function `aggregate` @@ -77,11 +77,11 @@ results in 2 (a third of 8, rounded down) entities. (This differs from `topperce ``` ::: -A definition that is equivalent to a `$count` expression after a collection-valued path was made in [OData-URL, section #odata-url-conventions#AddressingtheCountofaCollection]. +A definition that is equivalent to a `$count` expression after a collection-valued path was made in [#OData-URL#AddressingtheCountofaCollection]. ## ##subsec Function `isdefined` -Properties that are not explicitly mentioned in [`aggregate`](#Transformationaggregate) or [`groupby`](#Transformationgroupby) are considered to have been _aggregated away_. Since they are treated as having the null value in `$filter` expressions [OData-URL, section #odata-url-conventions#PathExpressions], the `$filter` expression `Product eq null` cannot distinguish between an instance containing the value for the null product and the instance containing the aggregated value across all products (where the `Product` has been aggregated away). +Properties that are not explicitly mentioned in [`aggregate`](#Transformationaggregate) or [`groupby`](#Transformationgroupby) are considered to have been _aggregated away_. Since they are treated as having the null value in `$filter` expressions [#OData-URL#PathExpressions], the `$filter` expression `Product eq null` cannot distinguish between an instance containing the value for the null product and the instance containing the aggregated value across all products (where the `Product` has been aggregated away). The function `isdefined` can be used to determine whether a property is present or absent in an instance. It takes a [single-valued property path](#SingleValuedPropertyPath) as its only parameter and returns true if the property is present in the instance for which the expression containing the `isdefined` function call is evaluated. A present property can still have the null value; it can represent a grouping of null values, or an aggregation that results in a null value. diff --git a/odata-data-aggregation-ext/7 Examples.md b/odata-data-aggregation-ext/7 Examples.md index 8f456b35..20aafd33 100644 --- a/odata-data-aggregation-ext/7 Examples.md +++ b/odata-data-aggregation-ext/7 Examples.md @@ -1347,7 +1347,7 @@ works differently: `descendants` is the parameter $T$ of `ancestors` and operate Besides changes to the structural properties of the entities in a hierarchical collection, hierarchy maintenance involves changes to the parent-child relationships. ::: example -Example ##ex: Move a sales organization Switzerland under the parent EMEA Central by binding the parent navigation property to EMEA Central [OData-JSON, section #odata-json-format#BindOperation]: +Example ##ex: Move a sales organization Switzerland under the parent EMEA Central by binding the parent navigation property to EMEA Central [#OData-JSON#BindOperation]: ```json PATCH /service/SalesOrganizations('Switzerland') Content-Type: application/json @@ -1370,7 +1370,7 @@ DELETE /service/SalesOrganizations('Switzerland')/Superordinate/$ref ::: ::: example -Example ##ex_refconstr: If the parent navigation property contained a referential constraint for the key of the target [OData-CSDL, section #odata-csdl-json#ReferentialConstraint], +Example ##ex_refconstr: If the parent navigation property contained a referential constraint for the key of the target [#OData-CSDL#ReferentialConstraint], ```xml @@ -1386,7 +1386,7 @@ Example ##ex_refconstr: If the parent navigation property contained a referentia ``` -then alternatively the property taking part in the referential constraint [OData-Protocol, section #odata-protocol#UpdateaPrimitiveProperty] could be changed to EMEA Central: +then alternatively the property taking part in the referential constraint [#OData-Protocol#UpdateaPrimitiveProperty] could be changed to EMEA Central: ```json PATCH /service/SalesOrganizations('Switzerland') Content-Type: application/json diff --git a/odata-data-aggregation-ext/meta.yaml b/odata-data-aggregation-ext/meta.yaml index 41e3fc88..db75f9c4 100644 --- a/odata-data-aggregation-ext/meta.yaml +++ b/odata-data-aggregation-ext/meta.yaml @@ -1,3 +1,5 @@ +name: OData-Data-Agg +url: https://docs.oasis-open.org/odata/odata-data-aggregation-ext/v4.0/odata-data-aggregation-ext-v4.0.html pagetitle: OData Extension for Data Aggregation Version 4.0 subtitle: Committee Specification 03 filename: odata-data-aggregation-ext-v4.0-cs03 diff --git a/odata-json-format/16 Bound Function.md b/odata-json-format/16 Bound Function.md index 48ea8e2a..27e447c5 100644 --- a/odata-json-format/16 Bound Function.md +++ b/odata-json-format/16 Bound Function.md @@ -285,8 +285,8 @@ Content-Type: application/json ::: Alternatively, values of non-binding parameters MAY be specified as common expressions -[OData-URL, section #odata-url-conventions#CommonExpressionSyntax]. In the case of a bound action -these MAY contain path expressions [OData-URL, section #odata-url-conventions#PathExpressions], which +[#OData-URL#CommonExpressionSyntax]. In the case of a bound action +these MAY contain path expressions [#OData-URL#PathExpressions], which the service evaluates on the binding parameter value. Such parameters are encoded as name/value pairs where the name is the name of the parameter followed by `@expression` and the value is the common expression. As the following example demonstrates, @@ -325,7 +325,7 @@ Content-Type: application/json ::: Inside a batch request the common expressions can also be value references -starting with `$`, as introduced in [OData-Protocol, section #odata-protocol#ReferencingValuesfromResponseBodies]. +starting with `$`, as introduced in [#OData-Protocol#ReferencingValuesfromResponseBodies]. Non-binding parameters that are nullable or annotated with the term [`Core.OptionalParameter`]($$$OData-VocCore$$$#OptionalParameter) defined in diff --git a/odata-json-format/4 Common Characteristics.md b/odata-json-format/4 Common Characteristics.md index 145e9b71..fed9b030 100644 --- a/odata-json-format/4 Common Characteristics.md +++ b/odata-json-format/4 Common Characteristics.md @@ -365,7 +365,7 @@ metadata document of a different service ### ##subsubsec Control Information: `count` (`odata.count`) The `count` control information occurs only in responses and -can annotate any collection, see [OData-Protocol, section #odata-protocol#SystemQueryOptioncount]. +can annotate any collection, see [#OData-Protocol#SystemQueryOptioncount]. Its value is an `Edm.Int64` value corresponding to the total count of members in the collection represented by the request. @@ -538,8 +538,8 @@ For [media entities](#MediaEntity) and [stream properties](#StreamProperty) at least one of the control information `mediaEditLink` and `mediaReadLink` MUST be included in responses if they don\'t follow standard URL conventions as defined -in [OData-URL, section #odata-url-conventions#AddressingaProperty] -and [OData-URL, section #odata-url-conventions#AddressingtheMediaStreamofaMediaEntity], or if +in [#OData-URL#AddressingaProperty] +and [#OData-URL#AddressingtheMediaStreamofaMediaEntity], or if [`metadata=full`](#metadatafullodatametadatafull) is requested. diff --git a/odata-json-format/meta.yaml b/odata-json-format/meta.yaml index a17de4fe..b6d120e7 100644 --- a/odata-json-format/meta.yaml +++ b/odata-json-format/meta.yaml @@ -1,3 +1,5 @@ +name: OData-JSON +url: https://docs.oasis-open.org/odata/odata-json-format/v4.02/odata-json-format-v4.02.html pagetitle: OData JSON Format Version 4.02 subtitle: Committee Specification Draft 02 filename: odata-json-format-v4.02-csd02 diff --git a/odata-protocol/11 Data Service Requests.md b/odata-protocol/11 Data Service Requests.md index 1016f9fc..e122e92a 100644 --- a/odata-protocol/11 Data Service Requests.md +++ b/odata-protocol/11 Data Service Requests.md @@ -231,7 +231,7 @@ GET http://host/service/Products(1)/Name #### ##subsubsubsec Requesting Stream Properties If the property being requested has type `Edm.Stream` (see -[OData-URL, section #odata-url-conventions#AddressingaProperty]), the media type of the response is the +[#OData-URL#AddressingaProperty]), the media type of the response is the media type of the stream, subject to content type negotiation based on the [`Accept`](#HeaderAccept) header of the request. The response body is the octet-stream that represents the raw @@ -411,7 +411,7 @@ expand item is evaluated relative to the retrieved resource being expanded. For a full description of the syntax used when building requests, see -[OData-URL, section #odata-url-conventions#SystemQueryOptionexpand]. +[#OData-URL#SystemQueryOptionexpand]. ::: example Example ##ex: for each customer entity within the Customers entity set the diff --git a/odata-protocol/11.4 Data Modification.md b/odata-protocol/11.4 Data Modification.md index d4175692..addff612 100644 --- a/odata-protocol/11.4 Data Modification.md +++ b/odata-protocol/11.4 Data Modification.md @@ -46,7 +46,7 @@ If optimistic concurrency control is required for a resource, the service MUST include an [`ETag`](#HeaderETag) header in a response to a `GET` request to the resource, and MAY include the ETag in a format-specific manner in responses containing that resource, -see for example [OData-JSON, section #odata-json-format#ControlInformationetagodataetag]. +see for example [#OData-JSON#ControlInformationetagodataetag]. The presence of an [`ETag`](#HeaderETag) header in a response does not imply in itself that the resource requires optimistic concurrency @@ -185,7 +185,7 @@ if the provided values do not match the service-determined values. Non-insertable properties include (and are not limited to) -- dependent properties that are tied to non-key properties of the principal entity through a referential constraint [OData-CSDL, section #odata-csdl-json#ReferentialConstraint] (informally: "denormalized" properties), +- dependent properties that are tied to non-key properties of the principal entity through a referential constraint [#OData-CSDL#ReferentialConstraint] (informally: "denormalized" properties), - properties annotated with the term [`Core.Computed`]($$$OData-VocCore$$$#Computed), see [OData-VocCore](#ODataVocCore), - properties listed as `NonInsertableProperties` of term [`Capabilities.InsertRestrictions`]($$$OData-VocCap$$$#InsertRestrictions), see [OData-VocCap](#ODataVocCap), @@ -376,7 +376,7 @@ If they are provided, services MUST either ignore the values in the request body Non-updatable properties include (and are not limited to) - key properties, -- dependent properties that are tied to non-key properties of the principal entity through a referential constraint [OData-CSDL, section #odata-csdl-json#ReferentialConstraint] (informally: "denormalized" properties), +- dependent properties that are tied to non-key properties of the principal entity through a referential constraint [#OData-CSDL#ReferentialConstraint] (informally: "denormalized" properties), - properties annotated with the terms [`Core.Computed`]($$$OData-VocCore$$$#Computed) or [`Core.Immutable`]($$$OData-VocCore$$$#Immutable), see [OData-VocCore](#ODataVocCore), - properties listed as `NonUpdatableProperties` of term [`Capabilities.UpdateRestrictions`]($$$OData-VocCap$$$#UpdateRestrictions), see [OData-VocCap](#ODataVocCap), diff --git a/odata-protocol/12 Conformance.md b/odata-protocol/12 Conformance.md index a84cadd6..13adc84b 100644 --- a/odata-protocol/12 Conformance.md +++ b/odata-protocol/12 Conformance.md @@ -153,7 +153,7 @@ with generic clients 13. SHOULD support the `$count` system query option ([section ##SystemQueryOptioncount]) 14. SHOULD support `$expand` ([section ##SystemQueryOptionexpand]) 15. SHOULD support the lambda operators `any` and `all` on navigation- -and collection-valued properties ([OData-URL, section #odata-url-conventions#LambdaOperators]) +and collection-valued properties ([#OData-URL#LambdaOperators]) 16. SHOULD support the `/$count` segment on navigation and collection properties ([section ##RequestingtheNumberofItemsinaCollection]) 17. SHOULD support `$orderby asc` and `desc` on individual properties @@ -171,7 +171,7 @@ Level](#OData40IntermediateConformanceLevel) 4. MUST support the `/$count` segment on navigation and collection properties ([section ##RequestingtheNumberofItemsinaCollection]) 5. MUST support the lambda operators `any` and `all` on navigation- and -and collection-valued properties ([OData-URL, section #odata-url-conventions#LambdaOperators]) +and collection-valued properties ([#OData-URL#LambdaOperators]) 6. MUST support the `$skip` system query option ([section ##SystemQueryOptionskip]) 7. MUST support the `$count` system query option ([section ##SystemQueryOptioncount]) 8. MUST support `$orderby` with `asc` and `desc` on individual properties diff --git a/odata-protocol/meta.yaml b/odata-protocol/meta.yaml index fc2265cc..3133d04e 100644 --- a/odata-protocol/meta.yaml +++ b/odata-protocol/meta.yaml @@ -1,3 +1,5 @@ +name: OData-Protocol +url: https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part1-protocol.html pagetitle: 'OData Version 4.02. Part 1: Protocol' subtitle: Committee Specification Draft 02 filename: odata-v4.02-csd02-part1-protocol diff --git a/odata-temporal-ext/4 Temporal Requests.md b/odata-temporal-ext/4 Temporal Requests.md index de3644ed..00bd6f1e 100644 --- a/odata-temporal-ext/4 Temporal Requests.md +++ b/odata-temporal-ext/4 Temporal Requests.md @@ -441,7 +441,7 @@ on the data valid at that point in time, including the query option For timeline entity sets the interval for filtering data is determined following the rules in section "[Propagation of Temporal Query Options](#PropagationofTemporalQueryOptions)" and evaluated as an additional criterion for `$filter` in the evaluation -sequence defined in [OData-Protocol, section #odata-protocol#SystemQueryOptions], +sequence defined in [#OData-Protocol#SystemQueryOptions], which is evaluated _after_ the query option `$apply`. ::: example diff --git a/odata-temporal-ext/meta.yaml b/odata-temporal-ext/meta.yaml index bab27ff9..c6dc6a35 100644 --- a/odata-temporal-ext/meta.yaml +++ b/odata-temporal-ext/meta.yaml @@ -1,3 +1,5 @@ +name: OData-Temporal +url: https://docs.oasis-open.org/odata/odata-temporal-ext/v4.0/odata-temporal-ext-v4.0.html pagetitle: OData Extension for Temporal Data Version 4.0 subtitle: Committee Specification Draft 04 filename: odata-temporal-ext-v4.0-csd04 diff --git a/odata-url-conventions/4 Resource Path.md b/odata-url-conventions/4 Resource Path.md index d73dfc20..bc00cc85 100644 --- a/odata-url-conventions/4 Resource Path.md +++ b/odata-url-conventions/4 Resource Path.md @@ -1086,7 +1086,7 @@ Content-Type: application/json Members of the JSON object also include parameters if the resource path is a function invocation or function import. In this case -parameters MUST be represented like parameters in an action invocation [OData-JSON, section #odata-json-format#ActionInvocation], +parameters MUST be represented like parameters in an action invocation [#OData-JSON#ActionInvocation], and in the resource path parentheses after the function name MUST be omitted. ::: example @@ -1105,7 +1105,7 @@ Content-Type: application/json ``` The previous request looks analogous to a bound function invocation with expressions (like in [example ##funcexpr]) -if it is written using implicit parameter aliases (see [OData-Protocol, section #odata-protocol#InlineParameterSyntax]). +if it is written using implicit parameter aliases (see [#OData-Protocol#InlineParameterSyntax]). ``` GET http://host/service/Employees(23)/self.PendingLeaveRequests ?StartDate=now() diff --git a/odata-url-conventions/5 Query Options.md b/odata-url-conventions/5 Query Options.md index 77ee0e88..34bd79ca 100644 --- a/odata-url-conventions/5 Query Options.md +++ b/odata-url-conventions/5 Query Options.md @@ -1706,7 +1706,7 @@ $filter=[FirstName,LastName] in [["John","Doe"],["Jane","Smith"]] ``` ::: -Entities are represented as structured literals as described in [OData-JSON, section #odata-json-format#Entity]. +Entities are represented as structured literals as described in [#OData-JSON#Entity]. Non-transient entities can alternatively be represented through their [resource path](#ResourcePath). ::: example diff --git a/odata-url-conventions/meta.yaml b/odata-url-conventions/meta.yaml index 9a879d98..b5a53d9c 100644 --- a/odata-url-conventions/meta.yaml +++ b/odata-url-conventions/meta.yaml @@ -1,3 +1,5 @@ +name: OData-URL +url: https://docs.oasis-open.org/odata/odata/v4.02/odata-v4.02-part2-url-conventions.html pagetitle: 'OData Version 4.02. Part 2: URL Conventions' subtitle: Committee Specification Draft 02 filename: odata-v4.02-csd02-part2-url-conventions