5 ms·

I think one popular name, independent of the format, is to call them documents. Or more specifically, the type of database which use them often runs under that

I think one popular name, independent of the format, is to call them documents. Or more specifically, the type of database which use them often runs under that term. Maybe specify it as data-document to not confuse it with freeform office-documents. But one problem is, that each format has slightly different ways it works. Some have nodes which support properties, some not. This makes building a proper query-language a bit more complicated if it should not end up ugly.

lucianbr 2y ago
What's the problem with nodes supporting or not some properties? For querying you can treat all nodes as supporting all things, and the user just needs to write a query that acutually works, which is what they would need to do anyway. Yes, if you want to make the query language reject as incorrect queries that specify a property on a node that can't have properties, it is messy. But is this really necessary? You can write faulty queries anyway. And it's not a programming language for complex systems, where it really helps to prevent mistakes early. SQL works fine with no type safety and so on.
- PurpleRamen 2y ago
  The problem is that you can't easily reuse a query with different formats, with a swallow designed language. You will still end up writing format-targeted queries, which then open the question of why you would even bother in the first place using a watered down language, instead of a format-optimized one.
jkaptur 2y ago
Another issue is that the term "document" is also used to refer to XML or HTML.
- PurpleRamen 2y ago
  XML is for data-exchange, competing with JSON and others. So I have no problem putting it to the data-documents, even though it's more a frankenstein. But HTML is an office-document, used for freetext, nobody really should use it for data, even though sometimes it's used that way.
  - hgyjnbdet 2y ago
    XML is also used, literally, for office documents (Word, Excel, etc).
    - PurpleRamen 2y ago
      So are JSON and YAML. The point is whether you have a programmatic and structured handling of a document's content, or whether it's random, where every line and word can demand for a different parser.

lucianbr 2y ago

What's the problem with nodes supporting or not some properties? For querying you can treat all nodes as supporting all things, and the user just needs to write a query that acutually works, which is what they would need to do anyway. Yes, if you want to make the query language reject as incorrect queries that specify a property on a node that can't have properties, it is messy. But is this really necessary? You can write faulty queries anyway. And it's not a programming language for complex systems, where it really helps to prevent mistakes early. SQL works fine with no type safety and so on.

PurpleRamen 2y ago
The problem is that you can't easily reuse a query with different formats, with a swallow designed language. You will still end up writing format-targeted queries, which then open the question of why you would even bother in the first place using a watered down language, instead of a format-optimized one.

jkaptur 2y ago

Another issue is that the term "document" is also used to refer to XML or HTML.

PurpleRamen 2y ago
XML is for data-exchange, competing with JSON and others. So I have no problem putting it to the data-documents, even though it's more a frankenstein. But HTML is an office-document, used for freetext, nobody really should use it for data, even though sometimes it's used that way.
- hgyjnbdet 2y ago
  XML is also used, literally, for office documents (Word, Excel, etc).
  - PurpleRamen 2y ago
    So are JSON and YAML. The point is whether you have a programmatic and structured handling of a document's content, or whether it's random, where every line and word can demand for a different parser.