Skip to Content
Last modified by Helena on 2025/09/10 11:19
From version 2.4
edited by Helena
on 2025/05/16 10:55
Change comment: There is no comment for this version
To version 3.5
edited by Helena
on 2025/05/16 10:58
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -21,10 +21,7 @@
21 21  The following rules apply to versioned artefacts:
22 22  
23 23  * All versioned SDMX artefacts MUST specify a version number.
24 -* The version number of immutable versioned SDMX artefacts MUST take the form X.Y.Z where X, Y, and Z are non-negative integers and MUST NOT contain leading zeroes. X is the MAJOR version, Y is the MINOR version, and Z is the PATCH version. Each element MUST increase numerically. For instance:
25 -
26 -1.9.0 -> 1.10.0 -> 1.11.0.
27 -
24 +* The version number of immutable versioned SDMX artefacts MUST take the form X.Y.Z where X, Y, and Z are non-negative integers and MUST NOT contain leading zeroes. X is the MAJOR version, Y is the MINOR version, and Z is the PATCH version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.
28 28  * Once an SDMX artefact with an X.Y.Z version has been shared externally or publicly released, the contents of that version MUST NOT be modified. That artefact version is considered stable. Any modifications MUST be released as a new version.
29 29  * MAJOR version zero (0.y.z) is for initial modelling. Anything MAY change at any time. The externally released or public artefact SHOULD NOT be considered stable.
30 30  * Version 1.0.0 defines the first stable artefact. The way in which the version number is incremented after this release is dependent on how this externally released or public artefact changes.
... ... @@ -31,16 +31,8 @@
31 31  * PATCH version Z (x.y.Z | x > 0) MUST be incremented if only backwards compatible property changes are introduced. A property change is defined as an internal change that does not affect the relationship to other artefacts. These are changes in the artefact's or artefact element's names, descriptions and annotations that MUST NOT alter their meaning.
32 32  * MINOR version Y (x.Y.z | x > 0) MUST be incremented if a new, backwards compatible element is introduced to a stable artefact. These are additional items in ItemScheme artefacts. It MAY be incremented if substantial new information is introduced within the artefact's properties. It MAY include PATCH level changes. PATCH version MUST be reset to 0 when MINOR version is incremented.
33 33  * MAJOR version X (X.y.z | X > 0) MUST be incremented if any backwards incompatible changes are introduced to a stable artefact. These often relate to deletions of items in ItemSchemes or to backwards incompatibility introduced due to changes in references to other artefacts. A MAJOR version change MAY also include MINOR and PATCH level changes. PATCH and MINOR version MUST be reset to 0 when MAJOR version is incremented.
34 -* A mutable version, e.g. used for externally released or public drafts or as prerelease, MUST be denoted by appending an EXTENSION that consists of a hyphen and a series of dot separated identifiers immediately following the PATCH version (x.y.z-EXT). Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. However, to foster harmonisation and general comprehension it is generally recommended to use the standard EXTENSION "**-draft**". Extended versions have a lower precedence than the associated stable version. An extended version indicates that the version is unstable and it might not satisfy the intended compatibility requirements as denoted by its associated stable version. When making changes to an SDMX artefact with an extended version number then one is not required to increment the version if those changes are kept within the allowed scope of the version increment from the previous version (if that existed), otherwise also here the before mentioned version increment rules for X.Y.Z apply. Concretely, a version X.0.0-EXT will allow for any changes, a version X.Y.0-EXT will allow only for MINOR changes and a version X.Y.Z-EXT will allow only for any PATCH changes, as defined above. EXTENSION examples:
35 -
36 -1.0.0-draft, 1.0.0-draft.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
37 -
38 -* Precedence refers to how versions are compared to each other when ordered. Precedence MUST be calculated by separating the version into MAJOR, MINOR, PATCH and EXTENSION identifiers in that order. Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: MAJOR, MINOR, and PATCH versions are always compared numerically. Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. When MAJOR, MINOR, and PATCH are equal, an extended version has lower precedence than a stable version. Example: 1.0.0-draft < 1.0.0. Precedence for two extended versions with the same MAJOR, MINOR, and PATCH version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or hyphens are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. A larger set of EXTENSION fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal. Example: 1.0.0-draft <
39 -
40 -1.0.0-draft.1 < 1.0.0-draft.prerelease < 1.0.0-prerelease < 1.0.0-prerelease.2 <
41 -
42 -1.0.0-prerelease.11 < 1.0.0-rc.1 < 1.0.0.
43 -
31 +* A mutable version, e.g. used for externally released or public drafts or as prerelease, MUST be denoted by appending an EXTENSION that consists of a hyphen and a series of dot separated identifiers immediately following the PATCH version (x.y.z-EXT). Identifiers MUST comprise only ASCII alphanumerics and hyphen [0-9A-Za-z-]. Identifiers MUST NOT be empty. Numeric identifiers MUST NOT include leading zeroes. However, to foster harmonisation and general comprehension it is generally recommended to use the standard EXTENSION "**-draft**". Extended versions have a lower precedence than the associated stable version. An extended version indicates that the version is unstable and it might not satisfy the intended compatibility requirements as denoted by its associated stable version. When making changes to an SDMX artefact with an extended version number then one is not required to increment the version if those changes are kept within the allowed scope of the version increment from the previous version (if that existed), otherwise also here the before mentioned version increment rules for X.Y.Z apply. Concretely, a version X.0.0-EXT will allow for any changes, a version X.Y.0-EXT will allow only for MINOR changes and a version X.Y.Z-EXT will allow only for any PATCH changes, as defined above. EXTENSION examples: 1.0.0-draft, 1.0.0-draft.1, 1.0.0-0.3.7, 1.0.0-x.7.z.92.
32 +* Precedence refers to how versions are compared to each other when ordered. Precedence MUST be calculated by separating the version into MAJOR, MINOR, PATCH and EXTENSION identifiers in that order. Precedence is determined by the first difference when comparing each of these identifiers from left to right as follows: MAJOR, MINOR, and PATCH versions are always compared numerically. Example: 1.0.0 < 2.0.0 < 2.1.0 < 2.1.1. When MAJOR, MINOR, and PATCH are equal, an extended version has lower precedence than a stable version. Example: 1.0.0-draft < 1.0.0. Precedence for two extended versions with the same MAJOR, MINOR, and PATCH version MUST be determined by comparing each dot separated identifier from left to right until a difference is found as follows: identifiers consisting of only digits are compared numerically and identifiers with letters or hyphens are compared lexically in ASCII sort order. Numeric identifiers always have lower precedence than non-numeric identifiers. A larger set of EXTENSION fields has a higher precedence than a smaller set, if all of the preceding identifiers are equal. Example: 1.0.0-draft < 1.0.0-draft.1 < 1.0.0-draft.prerelease < 1.0.0-prerelease < 1.0.0-prerelease.2 < 1.0.0-prerelease.11 < 1.0.0-rc.1 < 1.0.0.
44 44  * The reasons for version changes MAY be documented in brief form in an artefact's annotation of type "CHANGELOG".
45 45  
46 46  == 14.3 Backus–Naur Form Grammar for Valid SDMX 3.0(.0) Semantic Versions ==
... ... @@ -159,22 +159,14 @@
159 159  
160 160  Reduced version (without original SemVer "build metadata") from: [[__https:~~/~~/regex101.com/r/Ly7O1x/3/__https:~~/~~/regex101.com/r/Ly7O1x/3/>>https://https:regex101.comrLy7O1x3https:regex101.comrLy7O1x3]]
161 161  
162 -^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-
151 +^(?P<major>0|[1-9]\d*)\.(?P<minor>0|[1-9]\d*)\.(?P<patch>0|[1-9]\d*)(?:-(?P<extension>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?$
163 163  
164 -9]\d*)(?:-(?P<extension>(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-
165 -
166 -]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?$
167 -
168 168  And one with numbered capture groups instead (so cg1 = major, cg2 = minor, cg3 = patch and cg4 = extension) that is compatible with ECMA Script (JavaScript), PCRE (Perl Compatible Regular Expressions, i.e. Perl, PHP and R), Python and Go.
169 169  
170 170  Reduced version (without original SemVer "build metadata") from: [[__https:~~/~~/regex101.com/r/vkijKf/1/__https:~~/~~/regex101.com/r/vkijKf/1/>>https://https:regex101.comrvkijKf1https:regex101.comrvkijKf1]]
171 171  
172 -^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-
157 +^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?$
173 173  
174 -9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-
175 -
176 -][0-9a-zA-Z-]*))*))?$
177 -
178 178  **Must I adopt semantic versioning rules when switching to SDMX 3.0?**
179 179  
180 180  No. If backwards compatibility with pre-existing tools and processes is required, then it is possible to continue using the previous versioning scheme (with up to two version parts MAJOR.MINOR). Semantic versioning is indicated only for those use cases where a proper artefact versioning is required. If versioning does not apply to some or all of your artefacts, then rather migrate to non-versioned SDMX 3.0 artefacts.
... ... @@ -201,92 +201,4 @@
201 201  
202 202  In practice, the migration approach will often mirror the way in which organisations have migrated between earlier SDMX versions. Rarely, the new data models used mixed SDMX standard versions in their dependencies, and if they did then standard conversions were put in place. A typical method is to first migrate the re-used artefacts from the previous SDMX version to SDMX 3.0 and while doing so to apply the appropriate new semantic version string. From that point onwards, you can enjoy the advantages of the new SDMX versioning features for all those artefacts that require appropriate versioning.
203 203  
204 -[[1>>path:#sdfootnote1anc||name="sdfootnote1sym"]] Regular expressions, as specified in [[__W3C XML Schema Definition Language (XSD)__>>url:https://www.w3.org/TR/xmlschema11-2/]][[ >>url:https://www.w3.org/TR/xmlschema11-2/]][[__1.1 Part 2: Datatypes__>>url:https://www.w3.org/TR/xmlschema11-2/]][[.>>url:https://www.w3.org/TR/xmlschema11-2/]]
205 -
206 -[[2>>path:#sdfootnote2anc||name="sdfootnote2sym"]] The seconds can be reported fractionally
207 -
208 -[[3>>path:#sdfootnote3anc||name="sdfootnote3sym"]] ISO 8601 defines alternative definitions for the first week, all of which produce equivalent results. Any of these definitions could be substituted so long as they are in relation to the reporting year start day.
209 -
210 -[[4>>path:#sdfootnote4anc||name="sdfootnote4sym"]] The rules for adding durations to a date time are described in the W3C XML Schema specification. See __[[http:~~/~~/www.w3.org/TR/xmlschema>>url:http://www.w3.org/TR/xmlschema-2/#adding-durations-to-dateTimes]][[->>url:http://www.w3.org/TR/xmlschema-2/#adding-durations-to-dateTimes]][[2/#adding>>url:http://www.w3.org/TR/xmlschema-2/#adding-durations-to-dateTimes]][[->>url:http://www.w3.org/TR/xmlschema-2/#adding-durations-to-dateTimes]][[durations>>url:http://www.w3.org/TR/xmlschema-2/#adding-durations-to-dateTimes]][[->>url:http://www.w3.org/TR/xmlschema-2/#adding-durations-to-dateTimes]][[to>>url:http://www.w3.org/TR/xmlschema-2/#adding-durations-to-dateTimes]][[dateTimes>>url:http://www.w3.org/TR/xmlschema-2/#adding-durations-to-dateTimes]]__[[ >>url:http://www.w3.org/TR/xmlschema-2/#adding-durations-to-dateTimes]]for further details.
211 -
212 -[[5>>path:#sdfootnote5anc||name="sdfootnote5sym"]] The Validation and Transformation Language is a standard language designed and published under the SDMX initiative. VTL is described in the VTL User and Reference Guides available on the SDMX website [[__https:~~/~~/sdmx.org__>>url:https://sdmx.org/]][[.>>url:https://sdmx.org/]]
213 -
214 -[[6>>path:#sdfootnote6anc||name="sdfootnote6sym"]] In this chapter, in order to distinguish VTL and SDMX model artefacts, the VTL ones are written in the Arial font while the SDMX ones in Courier New
215 -
216 -[[7>>path:#sdfootnote7anc||name="sdfootnote7sym"]] See also the section "VTL-DL Rulesets" in the VTL Reference Manual.
217 -
218 -[[8>>path:#sdfootnote8anc||name="sdfootnote8sym"]] The VTLMappings are used also for User Defined Operators (UDO). Although UDOs are envisaged to be defined on generic operands, so that the specific artefacts to be manipulated are passed as parameters at their invocation, it is also possible that an UDO invokes directly some specific SDMX artefacts. These SDMX artefacts have to be mapped to the corresponding aliases used in the definition of the UDO through the VtlMappingScheme and VtlMapping classes as well.
219 -
220 -[[9>>path:#sdfootnote9anc||name="sdfootnote9sym"]] For a complete description of the structure of the URN see the SDMX 2.1 Standards - Section 5 - Registry Specifications, paragraph 6.2.2 ("Universal Resource Name (URN)").
221 -
222 -[[10>>path:#sdfootnote10anc||name="sdfootnote10sym"]] The container-object-id can repeat and may not be present.
223 -
224 -[[11>>path:#sdfootnote11anc||name="sdfootnote11sym"]] i.e., the artefact belongs to a maintainable class
225 -
226 -[[12>>path:#sdfootnote12anc||name="sdfootnote12sym"]] Since these references to SDMX objects include non-permitted characters as per the VTL ID notation, they need to be included between single quotes, according to the VTL rules for irregular names.
227 -
228 -[[13>>path:#sdfootnote13anc||name="sdfootnote13sym"]] For the syntax of the VTL operators see the VTL Reference Manual
229 -
230 -[[14>>path:#sdfootnote14anc||name="sdfootnote14sym"]] In case the invoked artefact is a VTL component, which can be invoked only within the invocation of a VTL data set (SDMX Dataflow), the specific SDMX class-name (e.g. Dimension, TimeDimension, Measure or DataAttribute) can be deduced from the data structure of the SDMX Dataflow, which the component belongs to.
231 -
232 -[[15>>path:#sdfootnote15anc||name="sdfootnote15sym"]] If the Agency is composite (for example AgencyA.Dept1.Unit2), the agency is considered different even if only part of the composite name is different (for example AgencyA.Dept1.Unit3 is a different Agency than the previous one). Moreover the agency-id cannot be omitted in part (i.e., if a TransformationScheme owned by AgencyA.Dept1.Unit2 references an artefact coming from AgencyA.Dept1.Unit3, the specification of the agency-id becomes mandatory and must be complete, without omitting the possibly equal parts like AgencyA.Dept1)
233 -
234 -[[16>>path:#sdfootnote16anc||name="sdfootnote16sym"]] Single quotes are needed because this reference is not a VTL regular name. ^^19^^ Single quotes are not needed in this case because CL_FREQ is a VTL regular name.
235 -
236 -[[17>>path:#sdfootnote17anc||name="sdfootnote17sym"]] The result DFR(1.0.0) is be equal to DF1(1.0.0) save that the component SECTOR is called SEC
237 -
238 -[[18>>path:#sdfootnote18anc||name="sdfootnote18sym"]] Rulesets of this kind cannot be reused when the referenced Concept has a different representation.
239 -
240 -[[19>>path:#sdfootnote19anc||name="sdfootnote19sym"]] See also the section "VTL-DL Rulesets" in the VTL Reference Manual.
241 -
242 -[[20>>path:#sdfootnote20anc||name="sdfootnote20sym"]] If a calculated artefact is persistent, it needs a persistent definition, i.e. a SDMX definition in a SDMX environment. In addition, possible calculated artefact that are not persistent may require a SDMX definition, for example when the result of a nonpersistent calculation is disseminated through SDMX tools (like an inquiry tool).
243 -
244 -[[21>>path:#sdfootnote21anc||name="sdfootnote21sym"]] See the VTL 2.0 User Manual
245 -
246 -[[22>>path:#sdfootnote22anc||name="sdfootnote22sym"]] See the SDMX Standards Section 2 – Information Model
247 -
248 -[[23>>path:#sdfootnote23anc||name="sdfootnote23sym"]] Besides the mapping between one SDMX Dataflow and one VTL Data Set, it is also possible to map distinct parts of a SDMX Dataflow to different VTL Data Set, as explained in a following paragraph.
249 -
250 -[[24>>path:#sdfootnote24anc||name="sdfootnote24sym"]] E.g., if in the data structure there exist 3 Dimensions C,D,E having the role of MeasureDimension, they should be considered as a joint MeasureDimension Z=(C,D,E); therefore when the description says “each possible value Cj of the MeasureDimension …” it means “each possible combination of values (Cj, Dk, Ew) of the joint MeasureDimension Z=(C,D,E)”.
251 -
252 -[[25>>path:#sdfootnote25anc||name="sdfootnote25sym"]] A typical example of this kind is the validation, and more in general the manipulation, of individual time series belonging to the same Dataflow, identifiable through the DimensionComponents of the Dataflow except the TimeDimension. The coding of these kind of operations might be simplified by mapping distinct time series (i.e. different parts of a SDMX Dataflow) to distinct VTL Data Sets.
253 -
254 -[[26>>path:#sdfootnote26anc||name="sdfootnote26sym"]] Please note that this kind of mapping is only an option at disposal of the definer of VTL Transformations; in fact it remains always possible to manipulate the needed parts of SDMX Dataflows by means of VTL operators (e.g. “sub”, “filter”, “calc”, “union” …), maintaining a mapping one-to-one between SDMX Dataflows and VTL Data Sets.
255 -
256 -[[27>>path:#sdfootnote27anc||name="sdfootnote27sym"]] This definition is made through the ToVtlSubspace and ToVtlSpaceKey classes and/or the FromVtlSuperspace and FromVtlSpaceKey classes, depending on the direction of the mapping (“key” means “dimension”). The mapping of Dataflow subsets can be applied independently in the two directions, also according to different Dimensions. When no Dimension is declared for a given direction, it is assumed that the option of mapping different parts of a SDMX Dataflow to different VTL Data Sets is not used.
257 -
258 -[[28>>path:#sdfootnote28anc||name="sdfootnote28sym"]] As a consequence of this formalism, a slash in the name of the VTL Data Set assumes the specific meaning of separator between the name of the Dataflow and the values of some of its Dimensions.
259 -
260 -[[29>>path:#sdfootnote29anc||name="sdfootnote29sym"]] This is the order in which the dimensions are defined in the ToVtlSpaceKey class or in the FromVtlSpaceKey class, depending on the direction of the mapping.
261 -
262 -[[30>>path:#sdfootnote30anc||name="sdfootnote30sym"]] It should be remembered that, according to the VTL consistency rules, a given VTL dataset cannot be the result of more than one VTL Transformation.
263 -
264 -[[31>>path:#sdfootnote31anc||name="sdfootnote31sym"]] If these DimensionComponents would not be dropped, the various VTL Data Sets resulting from this kind of mapping would have non-matching values for the Identifiers corresponding to the mapping Dimensions (e.g. POPULATION and COUNTRY). As a consequence, taking into account that the typical binary VTL operations at dataset level (+, -, *, / and so on) are executed on the observations having matching values for the identifiers, it would not be possible to compose the resulting VTL datasets one another (e.g. it would not be possible to calculate the population ratio between USA and CANADA).
265 -
266 -[[32>>path:#sdfootnote32anc||name="sdfootnote32sym"]] In case the ordered concatenation notation is used, the VTL Transformation described above, e.g. ‘DF1(1.0)/POPULATION.USA’ := DF1(1.0) [ sub INDICATOR=“POPULATION”, COUNTRY=“USA”], is implicitly executed. In order to test the overall compliance of the VTL program to the VTL consistency rules, it has to be considered as part of the VTL program even if it is not explicitly coded.
267 -
268 -[[33>>path:#sdfootnote33anc||name="sdfootnote33sym"]] If the whole DF2(1.0) is calculated by means of just one VTL Transformation, then the mapping between the SDMX Dataflow and the corresponding VTL dataset is one-to-one and this kind of mapping (one SDMX Dataflow to many VTL datasets) does not apply.
269 -
270 -[[34>>path:#sdfootnote34anc||name="sdfootnote34sym"]] This is possible as each VTL dataset corresponds to one particular combination of values of INDICATOR and COUNTRY.
271 -
272 -[[35>>path:#sdfootnote35anc||name="sdfootnote35sym"]] The mapping dimensions are defined as FromVtlSpaceKeys of the FromVtlSuperSpace of the VtlDataflowMapping relevant to DF2(1.0).
273 -
274 -[[36>>path:#sdfootnote36anc||name="sdfootnote36sym"]] the symbol of the VTL persistent assignment is used (<-)
275 -
276 -[[37>>path:#sdfootnote37anc||name="sdfootnote37sym"]] The result is persistent in this example but it can be also non persistent if needed.
277 -
278 -[[38>>path:#sdfootnote38anc||name="sdfootnote38sym"]] In case the ordered concatenation notation from VTL to SDMX is used, the set of Transformations described above is implicitly performed; therefore, in order to test the overall compliance of the VTL program to the VTL consistency rules, these implicit Transformations have to be considered as part of the VTL program even if they are not explicitly coded.
279 -
280 -[[39>>path:#sdfootnote39anc||name="sdfootnote39sym"]] Through SDMX Constraints, it is possible to specify the values that a Component of a Dataflow can assume.
281 -
282 -[[40>>path:#sdfootnote40anc||name="sdfootnote40sym"]] By using represented variables, VTL can assume that data structures having the same variables as identifiers can be composed one another because the correspondent values can match.
283 -
284 -[[41>>path:#sdfootnote41anc||name="sdfootnote41sym"]] A Concept becomes a Component in a DataStructureDefinition, and Components can have different LocalRepresentations in different DataStructureDefinitions, also overriding the (possible) base representation of the Concept.
285 -
286 -[[42>>path:#sdfootnote42anc||name="sdfootnote42sym"]] The representation given in the DSD should obviously be compatible with the VTL data type.
287 -
288 -[[43>>path:#sdfootnote43anc||name="sdfootnote43sym"]] Unidimensional datasets are those with a single 'indicator' or 'series code' dimension.
289 -
290 -[[44>>path:#sdfootnote44anc||name="sdfootnote44sym"]] A list of commonly used locales can be found in the Java supported locales: __[[https:~~/~~/www.oracle.com/java/technologies/javase/jdk8>>url:https://www.oracle.com/java/technologies/javase/jdk8-jre8-suported-locales.html]][[->>url:https://www.oracle.com/java/technologies/javase/jdk8-jre8-suported-locales.html]][[jre8>>url:https://www.oracle.com/java/technologies/javase/jdk8-jre8-suported-locales.html]][[->>url:https://www.oracle.com/java/technologies/javase/jdk8-jre8-suported-locales.html]][[suported>>url:https://www.oracle.com/java/technologies/javase/jdk8-jre8-suported-locales.html]][[->>url:https://www.oracle.com/java/technologies/javase/jdk8-jre8-suported-locales.html]][[locales.html>>url:https://www.oracle.com/java/technologies/javase/jdk8-jre8-suported-locales.html]]__[[url:https://www.oracle.com/java/technologies/javase/jdk8-jre8-suported-locales.html]]
291 -
292 -[[45>>path:#sdfootnote45anc||name="sdfootnote45sym"]] yyyy represents the calendar year while YYYY represents the year of the week, which is only relevant for 53 week years
185 +