Next in thread →
Next in month →
Re: [xml-dev] 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.
Next in thread →
Next in month →