#524 Convert XML format of styles to JSON

[Stéphane Aulery]

Hi Mark,

I did the first part which is the conversion itself. Remain the hard task to rewrite the style editor for writing the Json file from PHP arrays.

Regards,

[Mark Grimshaw]

Great. Let me know what I can do to help.

Mark

[Stéphane Aulery]

I continue this evening trying to modify only the writing of the file in the editor. Afterwards we will see together if there are improvements to be made on the PHP format or representation or on other structures and treatments.

Is there a reason for the bibliography entry to be broken down into common and types and for resource to be renamed to types in the PARSEXML object?

[Mark Grimshaw]

If you're referring to this:
$this->types = $raw_style_formater["bibliography"]["resource"];

then, no, I can't think of any reason. perhaps 'resourceTypes' might be more precise and informative.

Mark

[Stéphane Aulery]

Ok, I seek to limit the disparities between the format and the structure PHP.

[Stéphane Aulery]

I added code for writing a style file in JSON format without removing the XML format. The file written is called mystyle.2.json so as not to overwrite mystyle.json.

Is it useful to group resources and other "footnote" entries into two subarrays "resource" and "common"?

Currently resource entries are written twice to foonote but those in the sub-array are not read.

Is it useful to restructure PARSESTYLEJSON so that $this->common and $this->types become $this->bibliography["common"] and $this->bibliography["resource"]? This match the file structure. Same thing for footnote.

---

Some entries are defined like an array instead of a string in 2.json (ambiguousTemplate, ibid, idem, opcit...). Not sure is that make a difference.

[Mark Grimshaw]

I think leave the ambiguousTemplate etc. array/string as is. I think it's something that could be looked at later—I've been aware for some time that there is a discrepancy but need to find the time to look more closely.

Is it useful to group resources and other "footnote" entries into two subarrays "resource" and "common"?
Is it useful to restructure PARSESTYLEJSON so that $this->common and $this->types become $this->bibliography["common"] and $this->bibliography["resource"]? This match the file structure. Same thing for footnote.

Both good ideas I think.

Mark

[Stéphane Aulery]

If I can restructure with array then so I wonder the scope of this modification. There is a lot of occurrence of footnote and bibliography? The final step would be to replace PARSESTYLEJSON class by a single function returning an array.

[Mark Grimshaw]

Hi Stéphane,

You're more familiar with JSON than I am and are now closer to the code and changes you have made so do what you think best.

There is no reason academically/bibliographically to separate things into separate structures.

Mark

[Stéphane Aulery]

It's separate because you followed a path of technical reasoning. Despite this I find differences between the structure of the file and the structure in memory after loading. I also can't find a direct relationship between the layout of the editor and the format of the file for all the elements. I would like to reduce it.

I changed the file format but it was almost a mechanical conversion. I don't have a good understanding of this part of the code.

I wouldn't want to make a mistake changing on one side writing and loading with the formatting stopping working silently.

[Mark Grimshaw]

OK. Well let me know when I can test the new formats loading and saving in the editor. I haven't tried yet because I don't want to mess up anything you're in the middle of.

Mark

[Stéphane Aulery]

At the moment the loading of style files is correct. The writing of style files is correct but is done in separate files so as not to overwrite the active files.

[Stéphane Aulery]

JSON is a byte like the output or var_dump(), print_r() or var_export(). It can declare arrays with [] syntax and objects with {} syntax (JSON spec).

I use the $associative = TRUE option with json_decode(). So when you write an array you also get an array instead of an object.

Apart from this subtlety, it's the same that if you use the serialize()/unserialize() functions, you don't really need to know the format beyond the fact that it reproduces the PHP structure of a variable.

The advantage of this format is that it can be used by other languages than PHP and can be exchanged easily unlike serialized PHP.

If you are not confortable with JSON we can pick the output of var_export() or serialize().

[Mark Grimshaw]

I'm fine enough with JSON.

I'll have a look this weekend at the initial loading and writing.

Mark

[Stéphane Aulery]

Thanks. For my part, I will take care of correcting the writing of component.json files so that they are no longer a concatenation of strings.

[Mark Grimshaw]

Hi Stéphane,

Trying to copy the APA style, I get the attached trying to save the first screen.

We must also have a means to convert a user's custom style from XML to JSON.

Mark

[Stéphane Aulery]

This error is normal if you make a copy of the editor. The editor does not write the .json file at the moment but a .2.json file. Do the first copy by hand.

The XML/JSON conversion code is just 10 more line than the previous code. Not a big deal. But since the version number update is broken I don't think it's possible to convert custom styles without error.

[Mark Grimshaw]

OK. I think, though, that once you're done with the conversion we will need to find a way to convert custom styles on upgrade. We can't have users complaining that their styles are no longer usable.

Mark

[Stéphane Aulery]

When I said error, I meant lossless. I will write the conversion program after analyzing all published style versions.

[Mark Grimshaw]

Great!

Mark

[Stéphane Aulery]

Now I try to convert the style editor to read footnote>common and footnote>resource sections from cfb.json, and write footnote>common and footnote>resource without the old structure in cfb.2.json but I get defaults values showing fields are not well loaded. I can't figure where is my error in arrayToTemplate().

I don't try to use the style to format with the rules under footnote>common and footnote>resource.

And what I try to do don't make sense if the fields inside setDefaults() remain like footnote_primaryTwoCreatorsSep instead of footnote_common_primaryTwoCreatorsSep.

Wouldn't it be easier to populate the HTML and retrieve the values by simply flattening the structure of the JSON by placing an underscore to represent each level of the file?

For example citation_creatorSepNextLast instead of cite_creatorSepNextLast?

Could you help me?

[Mark Grimshaw]

Hi Stéphane,

I'm not sure what you're asking regarding:
citation_creatorSepNextLast
and
cite_creatorSepNextLast

as both have an '_'

[Stéphane Aulery]

If I understand cite_creatorSepNextLast is the name of the field on HTML screen, and citation_creatorSepNextLast its name inside the JSON. I ask if it is that and if there is no interest in it corresponding.

[Mark Grimshaw]

I don't really know how you've restructured things so I can't really answer. The field is to do with in-text citations and is, for exaple, the 'and' below:
According to some "blah, blah, blah" (Grimshaw, Grimshaw-Aagaard, and Aulery 2023).

That is, it is part of the citation block (as I previously structured it) and not part of the bibliography/references/footnotes.

Mark