Path: ...!news.nobody.at!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Malcolm McLean <malcolm.arthur.mclean@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Add JSON, XML, CSV to Baby X resource compiler
Date: Tue, 21 May 2024 12:59:28 +0100
Organization: A noiseless patient Spider
Lines: 91
Message-ID: <v2i2b0$j091$1@dont-email.me>
References: <v2cjht$3b3om$1@dont-email.me> <v2dv70$3jm1q$1@dont-email.me>
 <xFK2O.67490$29Ia.34879@fx13.iad> <v2g86i$53en$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 21 May 2024 13:59:28 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="db8c0bb6b7833b719005776dfb0822e4";
	logging-data="622881"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19dKb0ejRPOiS7aYu16eLWcUFrSAk45zlI="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:n/CzHaJxpaoiF4h83RYLwiyAhNc=
Content-Language: en-GB
In-Reply-To: <v2g86i$53en$1@dont-email.me>
Bytes: 4848

On 20/05/2024 20:27, bart wrote:
> On 20/05/2024 17:14, Scott Lurndal wrote:
>> bart <bc@freeuk.com> writes:
>>> On 19/05/2024 11:16, Malcolm McLean wrote:
>>>> The Baby X resource compiler takes data - fonts, images, audio, strings
>>>> - and converts them into C source so that they can be read by C 
>>>> programs
>>>> without relying on external data files.
>>>>
>>>> An obvious extension is to take in structured data. Adding SQL and
>>>> querying a database would unfortuately mean extending the program so
>>>> that it could only run on a large machine with a SQL server running, 
>>>> and
>>>> isn't really a viable proposition. However JSON, XML, and CSV are
>>>> commonly used to pass small to medium amounts of data about.
>>>>
>>>> I've made a start on supporting CSV with the "<dataframe>" tag. CSV 
>>>> data
>>>> is tabular and two dimensional, and lends itself to an arrray of simple
>>>> structures. JSON And XML can of course represent more complex data, 
>>>> with
>>>> hierarchy. The dataframe tag is still very experimental. I've never 
>>>> used
>>>> it for anything practical.
>>>>
>>>> So what would be the best approach to putting in JSON and XML support?
>>>
>>> I've only briefly used XML.
>>
>> That's clear from what you write below.
> 
> I have enough experience to know that it CAN represent disparate data 
> just like I said, since I've had to generate exactly such files as input 
> into another application that required such data.
> 
> 
>>> Even if the file does represent a simple list of records for example,
>>> you won't know that without reading it and analysing it.
>>
>> Study XML Schema.
> 
> I have no interest in studying XML or every using again. I already 
> stated in an earlier post that it's more complicated than it looks.
> 
> 
>     https://en.wikipedia.org/wiki/XML_Schema_(W3C)
>>
>> Then study XSL.     https://en.wikipedia.org/wiki/XSLT
>>
>> XML is a markup language.   A subset of SGML.  HTML is a non-proper
>> and non-regular subset of XML.
>>
>> It's far more flexible and useful than a set of comma-separated-values.
> 
> And, therefore, 'chaotic' it what can be represented, even if 
> technically it can be described by a recursively defined syntax.
> 
> Or you need to know is that XML can represent the syntactic structure of 
> most programming languages, and we all know how easy that is to 
> represent as a fixed set of initialised C data structures hardcoded into 
> a source file.
>
That is one answer. XML and JSON are trees, with certain contraints on 
the nodes. So we could devise a C struct which represents a node, and 
spit out a rooted tree.

> 
>>>
>>> I looked online at an XML to CSV converter, which I thought would do
>>> something clever, but it seems to just turn each XML line into one
>>> string per line.
>>
>> You use stylesheets (XSL) with a stylesheet processor to make
>> arbitrary transformations to an XML document.  The output can
>> be XML, HTML, CSV, or any custom format required for an application.
> 
> The OP wanted to be able to directly process XML; I suggest that it 
> first be transformed into something more regular.
> 
That seems to be a better approach. Data represents something in the 
real world. And normally there are a lot of constraints on it. A 
temperature measurement might be missing, but it must be real, it can't 
be imaginary. Even though XML will of course allow you to put "<REAL>" 
and "<IMAGINARY>" tags under the temperature tag if you so desire.

But how to do that whilst keeping the program usable?

-- 
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm