Re: Invisible XML 1.0 spec has been published

I actually see a lot of utility for ixml in rdf, especially if you use
custom simple types such as
"rgba(64,128,64,0.5)"^^Functions:_ColorFunctions as atomic values. This
could be mapped to an ixml parser that would generate:

<map>
    <number key="red">64</number>
    <number key="green">128</number>
    <number key="blue">64</number>
    <number key="alpha">0.5</number>
    <string key="function">rgba</string>
</map>

Which then can be translated with any xslt processor to
{"red":64,"green":128,"blue":64,"alpha":0.5:"function":"rgba"} as JSON or
[:red 64; :green:128; :blue:54; :alpha 0.5; :function Function:_rgba] as
Turtle.

What's the value in this? In a knowledge graph such functional attributes
are difficult to parse, especially on ingest. An ixml parser could reduce
re this complexity, especially across heterogeneous requirements.

On Sat, Jun 11, 2022, 16:04 John Cowan <[email protected]> wrote:

>
>
> On Fri, Jun 10, 2022 at 4:12 PM C. M. Sperberg-McQueen <
> [email protected]> wrote:
>
>
>> If by "create a parser" you mean write a program, in some programming
>> language, which can parse sentences of a particular language, then
>> nothing could be further from the truth.
>
>
> It depends on whether you think of an ixml grammar as a program or not, I
> suppose.  Admittedly it would be a very high-level program.
>
>
>> TL;DR Why, you ask, is the Invisible XML group trying to re-invent the
>> wheel?  Because we think things will work better with the axle in the
>> center of the wheel.
>>
>
> Well said.
>
>  As to binary data, however, ixml seems to be defined in terms of Unicode
> codepoints/characters, so it would need a preprocessor to convert bytes to
> characters according to some convention such as Latin-1 or
> ASCII-with-escapes, such as mapping 2B 5C 81 77 to "+\\\x81w" or
> alternatively "+\x5c\x81w" or even "2b5c8177".  Ixml grammars could handle
> any of these.
>