Is there any way to separate multiple entries within one data field?

[MartinaWen]

I just got started with Obsidian and also new to the Dataview functionality.
While the export of my data works really well with this plugin, i was wondering if there was a way to separate mutliple entries within one data field?
Dataview shows multiple entries as an enumeration, which get's lost during export to csv. I suppose a workaround is to always combine sparate words with an underscore, but maybe there is any easy way to avoid this.

[pwflint]

Upvoting this FR. I get the same result.

Use case: I track my morning and evening heart rate daily. When I export to csv using plugin I get a result similar to:
date1,amHR,pmHR
2023-05-16 2023-05-17 2023-05-19 2023-05-20 2023-05-21 2023-05-22, 55 51 58 58 62, 96 95 95 95 97

What I expect is:
date1,amHR,pmHR
2023-05-16, 2023-05-17, 2023-05-19, 2023-05-20, 2023-05-21, 2023-05-22, 55, 51, 58, 58, 62, 96, 95, 95, 95, 97

Headings are parsing appropriately but data values all import into a single cell.

Thx,
PWF

[maggaou]

@pwflint Hi. I'm just curious and trying to understand your problem — I'm not a developer. This is quote from Wikipedia:

CSV cannot naturally represent hierarchical or object-oriented data. This is because every CSV record is expected to have the same structure. CSV is therefore rarely appropriate for documents created with HTML, XML, or other markup or word-processing technologies.

In other words CSV doesn't offer any syntax for different field types — all fields are strings of text that doesn't include reserved characters. In case of field containing reserved characters its value can be surrounded with double quotes "field content". If the field contains double quotes then they should come with paired double quotes or double quotes could be escaped by backslash \". The plugin includes settings for using quotation marks around field values and converting newlines to [CR]. I'm not sure about the latter setting — is newlines forbidden in fields due to the way CSV‑import works in Excel or because of something else.

In any case GFM markdown spec defines tables as leaf blocks which are contrary to container blocks. Container blocks can contain other leaf blocks but leaf blocks contain only inline content such as bolded text __text__. However GFM‑tables can contain html‑tags which means Obsidian could in theory implement special functionality to Toggle bullet list, Toggle numbered list and Toggle checkbox status commands in the case they are used in tables. For now Obsidian uses different field types in properties using YAML‑syntax. In theory YAML could be used in GFM-table cells but then there is no markdown inline formatting because content is assumed to be YAML syntax. Pandoc's markdown spec defines grid tables which can include other markdown container blocks. I think the additional benefit of grid tables is small since data processing in Obsidian is highly focused on YAML and in case of working with custom data types some other tools must be used such as Power Query in Excel.

Markdown tables are not very powerful by nature. Markdown isn't suited to collect structured data but YAML could be used for that. When data is collected once a day, a new note with corresponding YAML could be used to capture that data. The purpose of markdown tables is not to capture data but to represent existing data. In case of over 30-40 rows tables become storage of data instead of a good representation of data. This is the main idea of upcoming dynamic views which treat tables as output form — not as a data source.