On Thu, 28 Mar 2024 at 12:41, Lorenzo Bertini <lorenzobertin...@gmail.com> wrote:
> Il giorno gio 28 mar 2024 alle ore 11:40 José Matos > <jaoma...@gmail.com> ha scritto: > > > > On Wed, 2024-03-27 at 11:02 -0400, Scott Kostyshak wrote: > > > Cool idea, Lorenzo! There have been some discussions in the past on > > > using standard formats, even for the .lyx file itself. I can see the > > > advantages of that but I don't know what the cost of converting to > > > them > > > is. > > > > > > Scott > > > > Typical answer to this: > > https://xkcd.com/927/ > > > > :-) > > > > It makes sense for us to use a standard format. > > Some of the questions then are: > > * which one is chosen (what is the most appropriate for our needs)? > > * what the are advantages and drawbacks from this change? > > * what is the transition plan? > > * what is the effort required for this transition? > > > > Best regards, > > -- > > José Abílio > > -- > > Ah, a classic xkcd. For once, however, the talk is about "removing" > one standard :) > Many standards aim at removing older standards :)! > * Which one to choose? > See research below. > > * The advantages and drawbacks > As already mentioned, using a more common format means > - people generally more familiar with the format > - having more tools able to produce them, easing the efforts of > publishers trying to provide layouts > - having parsers already available, for LyX and for people wanting > to manipulate them externally > The drawbacks that i can think of are > - migration always takes developer effort > - migration can take user effort too, to adapt to the new format > (this can be greatly mitigated by which format is chosen) > > * The transition plan: > The new format is introduced *alongside* the old format. The LyX > version that brings the format will have all layouts converted, but > will accept the old format too. This "transition period" can last > indefinitely. > In a way, that's how LyX works right now: you can import a very old document or layout, it should still work thanks to upgrade scripts. YAML, TOML, or something else would just be a new version (which means you must keep the version field: the format evolves a lot between versions). Here is the script that does the conversion: https://git.lyx.org/gitweb/?p=lyx.git;a=blob;f=lib/scripts/layout2layout.py;h=611639412a78e4235a55e41c890546f4e080c06f;hb=HEAD. > * The efforts required for the transition > We need to: > - write or choose a parser for the new format that maps a file to a > LyX's params > - write a converter from the old format to the new one > - convert all the files to the new formats and test them > > Here is some info I dug up regarding configuration formats. For pros > and cons I tried to limit them to one single aspect where they excel > or fail > - JSON: > . pros: most widely supported > . cons: not concise or readable, very distant from .layout > - TOML: > . pros: very easy to read and write, even for humans > . cons: not widespread, distant from .layout > - YAML: > . pros: very easy to read and write, very close to .layout > . cons: indentation is prone to syntax errors > - XML: > . pros: the one and only, supports validation through schemas, > widely supported > . cons: hard to read and write, very distant from .layout > All of these formats are rather well supported and far from shiny new things (I think all of them have at least a decade of existence). Regarding validation: XML Schema has many offsprings, such as JSON Schema ( https://json-schema.org/), with implementations that work on YAML and TOML ( https://json-schema-everywhere.github.io/toml). In any case, these schemas are extremely lacking compared to 21st-century XML validation (RelaxNG with Schematron). We currently have no validation, but it would be great to have it as part of the test suite. How well do these formats work with (long) strings? What's great with the current format is that you don't need to escape anything when LyX expects a string. This aspect of the design removes a huge source of typos. > I asked a chatbot to convert LyX's following layout extract into those > formats: > > LYX'S LAYOUT > > InsetLayout Marginal > LabelString Margin > LatexType command > Font > Size Small > EndFont > LabelFont > Color marginlabel > Size Small > EndFont > HTMLStyle > div.marginal { > border: 2px solid black; > font-style: normal; > } > EndHTMLStyle > End > > JSON: > > { > "InsetLayout": { > "LabelString": "Margin", > "LatexType": "command", > "Font": { > "Size": "Small" > }, > "LabelFont": { > "Color": "marginlabel", > "Size": "Small" > }, > "HTMLStyle": { > "div.marginal": { > "border": "2px solid black", > "font-style": "normal" > } > } > } > } > > TOML: > > [InsetLayout] > LabelString = "Margin" > LatexType = "command" > > [InsetLayout.Font] > Size = "Small" > > [InsetLayout.LabelFont] > Color = "marginlabel" > Size = "Small" > > [InsetLayout.HTMLStyle.div.marginal] > border = "2px solid black" > font-style = "normal" > > YAML: > > InsetLayout: > LabelString: Margin > LatexType: command > Font: > Size: Small > LabelFont: > Color: marginlabel > Size: Small > HTMLStyle: > div.marginal: > border: 2px solid black > font-style: normal > > XML: > > <InsetLayout> > <LabelString>Margin</LabelString> > <LatexType>command</LatexType> > <Font> > <Size>Small</Size> > </Font> > <LabelFont> > <Color>marginlabel</Color> > <Size>Small</Size> > </LabelFont> > <HTMLStyle> > <div.marginal> > <border>2px solid black</border> > <font-style>normal</font-style> > </div.marginal> > </HTMLStyle> > </InsetLayout> > > Obviously there are errors because it considered the CSS inside it as > part of the format. But I hope this gives you an impression of what > each format can give us. Personally, and for what it counts (very > little), my pick would the the closest to the original format, and > that would be YAML. > > Let me know what you think. > Lorenzo > -- > lyx-devel mailing list > lyx-devel@lists.lyx.org > http://lists.lyx.org/mailman/listinfo/lyx-devel >
-- lyx-devel mailing list lyx-devel@lists.lyx.org http://lists.lyx.org/mailman/listinfo/lyx-devel
