Merge branch 'bids-standard:master' into master

Release_Protocol.md

@@ -278,5 +278,5 @@ Update the following files in the BIDS website repository (https://github.com/bi
 
 ### 12. Sharing news of the release
 
-Please share news of the release on the [identified platforms](https://docs.google.com/spreadsheets/d/16SAGK3zG93WM2EWuoZDcRIC7ygPc5b7PDNGpFyC3obA/edit#gid=0).
+Please share news of the release on the [identified platforms](https://github.com/bids-standard/bids-specification?tab=readme-ov-file#BIDS-communication-channels).
 Please use our previous release posts as a guide.

pdf_build_src/remove_admonitions.py

@@ -47,7 +47,7 @@ def remove_admonitions(
                     counter += 1
                     continue
 
-                if not line.startswith(indent):
+                if line != "\n" and not line.startswith(indent):
                     is_admonition = False
 
                 if is_admonition:

pdf_build_src/tests/data/expected/README.md

@@ -19,3 +19,14 @@ Collapsible admonitions start with 3 questions marks (`???`).
 
 Collapsible admonitions that will be shown as expanded
 start with 3 questions marks and a plus sign (`???+`).
+
+
+
+Let's see
+
+-   [`UK biobank`](https://github.com/bids-standard/bids-examples/tree/master/genetics_ukbb)
+-   foo bar [`UK biobank`](https://github.com/bids-standard/bids-examples/tree/master/genetics_ukbb)
+
+More of the admonition
+
+And here we resume normal thing.

pdf_build_src/tests/data/input/README.md

@@ -25,3 +25,16 @@ come in different type. In aaddtion of the classical admonitions show above you
 
     Collapsible admonitions that will be shown as expanded
     start with 3 questions marks and a plus sign (`???+`).
+
+
+
+!!! example "non ordered list should be handle propeler"
+
+    Let's see
+
+    -   [`UK biobank`](https://github.com/bids-standard/bids-examples/tree/master/genetics_ukbb)
+    -   foo bar [`UK biobank`](https://github.com/bids-standard/bids-examples/tree/master/genetics_ukbb)
+
+    More of the admonition
+
+And here we resume normal thing.

src/common-principles.md

@@ -238,10 +238,14 @@ distinguish partial results from the raw data and share the latter.
 See [Storage of derived datasets](#storage-of-derived-datasets) for more on
 organizing derivatives.
 
-Similar rules apply to source data, which is defined as data before
-harmonization, reconstruction, and/or file format conversion (for example, E-Prime event logs or DICOM files).
-Storing actual source files with the data is preferred over links to
-external source repositories to maximize long term preservation,
+Similar rules apply to source data, which is defined as data
+before harmonization, reconstruction, and/or file format conversion
+(for example, E-Prime event logs or DICOM files).
+Retaining the source data is especially valuable
+in a case when conversion fails to preserve crucial metadata
+unique to specific acquisition setup.
+Storing actual source files with the data is preferred over links
+to external source repositories to maximize long term preservation,
 which would suffer if an external repository would not be available anymore.
 This specification currently does not go into the details of
 recommending a particular naming scheme for including different types of

src/modality-specific-files/electroencephalography.md

@@ -42,14 +42,10 @@ It is RECOMMENDED to use the European data format, or the BrainVision data
 format. It is furthermore discouraged to use the other accepted formats over
 these RECOMMENDED formats, particularly because there are conversion scripts
 available in most commonly used programming languages to convert data into the
-RECOMMENDED formats. The data in their original format, if different from the
-supported formats, can be stored in the [`/sourcedata` directory](../common-principles.md#source-vs-raw-vs-derived-data).
-
-The original data format is especially valuable in case conversion elicits the
-loss of crucial metadata specific to manufacturers and specific EEG systems. We
-also encourage users to provide additional meta information extracted from the
-manufacturer specific data files in the sidecar JSON file. Other relevant files
-MAY be included alongside the original EEG data in `/sourcedata`.
+RECOMMENDED formats.
+
+We encourage users to provide additional metadata extracted from the
+manufacturer-specific data files in the sidecar JSON file.
 
 Note the `RecordingType`, which depends on whether the data stream on disk
 is interrupted or not.

src/modality-specific-files/intracranial-electroencephalography.md

@@ -53,12 +53,8 @@ packages. Other formats that may be considered in the future should have a clear
 added advantage over the existing formats and should have wide adoption in the
 BIDS community.
 
-The data format in which the data was originally stored is especially valuable
-in case conversion elicits the loss of crucial metadata specific to
-manufacturers and specific iEEG systems. We also encourage users to provide
-additional meta information extracted from the manufacturer-specific data files
-in the sidecar JSON file. Other relevant files MAY be included alongside the
-original iEEG data in the [`/sourcedata` directory](../common-principles.md#source-vs-raw-vs-derived-data).
+We encourage users to provide additional metadata extracted from the
+manufacturer-specific data files in the sidecar JSON file.
 
 Note the RecordingType, which depends on whether the data stream on disk is interrupted or not.
 Continuous data is by definition 1 segment without interruption.

src/modality-specific-files/microscopy.md

@@ -59,9 +59,6 @@ Microscopy raw data MUST be stored in one of the following formats:
 
 -   [OME-ZARR/NGFF](https://ngff.openmicroscopy.org/latest/) (`.ome.zarr` directories)
 
-If different from PNG, TIFF, OME-TIFF, or OME-ZARR, the original unprocessed data in the native format MAY be
-stored in the [`/sourcedata` directory](../common-principles.md#source-vs-raw-vs-derived-data).
-
 ### Modality suffixes
 Microscopy data currently support the following imaging modalities:
 

src/modality-specific-files/motion.md

@@ -50,10 +50,6 @@ The number of columns in `_motion.tsv` files MUST equal the number of rows
 in the associated `_channels.tsv` file.
 All relevant metadata about a tracking systems is stored in accompanying sidecar `*_tracksys-<label>_motion.json` file.
 
-The source data from each tracking system in their original format, if different from `.tsv`,
-can be stored in the [`/sourcedata` directory](../common-principles.md#source-vs-raw-vs-derived-data).
-The original data format MAY hold more metadata than currently specified in the `*_motion.json` file.
-
 When multiple tracking systems are used to record motion or motion capture is used alongside the recording of other BIDS modalities and recordings should be interpreted together,
 it is advised to provide a possibility to synchronize recordings.
 The preferred way to do so is to use the acquisition time of the first data point of recordings and

src/modality-specific-files/near-infrared-spectroscopy.md

@@ -36,15 +36,6 @@ replicated  in the BIDS specification. This redundancy allows the data to be
 easily parsed by humans and machines that do not have a SNIRF reader at hand,
 which improves findability and tooling development.
 
-Raw NIRS data in the native format, if different from SNIRF, can also
-be stored in the [`/sourcedata`](../common-principles.md#source-vs-raw-vs-derived-data)
-directory along with code to convert the data to
-SNIRF in the [`/code`](../common-principles.md#storage-of-derived-datasets) directory.
-The unprocessed raw data should be stored in
-the manufacturer's format before any additional processing or conversion is applied.
-Retaining the native file format is especially valuable in a case when conversion elicits the
-loss of crucial metadata unique to specific manufacturers and NIRS systems.
-
 ### Terminology
 
 For proper documentation of NIRS recording metadata, it is important

src/schema/objects/formats.yaml

@@ -22,12 +22,12 @@ integer:
   display_name: Integer
   description: |
     An integer which may be positive or negative.
-  pattern: '[+-]?\d+'
+  pattern: ' *[+-]?\d+ *'
 number:
   display_name: Number
   description: |
     A number which may be an integer or float, positive or negative.
-  pattern: '[+-]?([0-9]+([.][0-9]*)?|[.][0-9]+)([eE][+-]?[0-9]+)?'
+  pattern: ' *[+-]?([0-9]+([.][0-9]*)?|[.][0-9]+)([eE][+-]?[0-9]+)? *'
 string:
   display_name: String
   description: |