Implement KDL 1.0.0 as a JSON authoring option/output format for Metadata Display Entities

[DiegoPino]

What?

If you have not read about KDL its not too late! Here https://kdl.dev give it a look

One of the issues I find constantly when authoring JSON (output) via Twig templates is that you have to handle output by keeping track of the commas, specially when merging two source data arrays (e.g Documents and Images) coming for a IIIF Manifest. But also because its really made for Machines (and works lovely/well) but not for humans to write. YAML on the other side has this thing about tabs/identations. And happens that keeping those in touch via a Twig Template (if you have tried to make the output pretty) is a nightmare!

So. KDL solves many of those issue, its quite verbose, simpler and we can of course (for the sake of the output) quickly serialized back into JSON on the fly to be e.g JSON-LD compliant of manifests, or GeoJSON, etc.

PHP library is there 👏 and there is even (not needed in our case yet since we are Core JSON/Storage is JSON, etc) a Query Language Spec/definition that looks pretty JMESPATH so neat too.

kdl-org/kdl#144

I will give this a try tomorrow (Sept 14th of 2021) after all our trainings and deliverables. I see some chances of making @alliomeria @aksm and @giancarlobi live easier.

Again, the idea here is that If you want to create JSON via a Twig template you can Create KDL and we transform the output. Easier to navigate. Hope you like the idea!

[zkat]

Hey! This is great!

One thing to keep in mind: KDL is not 1:1 convertible to and from JSON. You'd need to stick to a restricted subset called JSON-in-KDL/JiK.

That said, if you have a specific data format (like it seems you do), you can probably define a subset of KDL that you accept that will be convertible into JSON easily, so you don't need to worry about using JiK in that case. You'll just need to define your own translation layer.

[DiegoPino]

@zkat thanks for chiming in. True. My initial approach here is not to go for a 1:1 direct conversion but aim/help users with structured data authoring using Blue Prints (in our case #PHP Symfony's Twig). So the way I see this (my vision may shift as I try to implement the code of course) is.

• Users can build via KDL valid data structures (e.g your Website example which serves also as a good starting point for XML)
• The KDL is parsed into a Native Data structure in our language. In PHP almost anything can be serialized into Arrays and Objects. Things will fall out, comments, etc (etc requires me to read the specs deeper). That is Ok.
• The Final Desired Output is Serialized again (XML/JSON/etc).

Performance wise these is not great. But sometimes verbosity/ux wins over performance. Also do not see this as replacement of our current approach but an add-on. Of course native KDL output (without transformation) will be possible.

Here is an example of a Template that given a data source (contained in a data.someproperty structure) becomes a JSON-LD document:

https://github.com/esmero/archipelago-deployment/blob/1.0.0-RC2/d8content/metadatadisplays/iiif_manifest_3.0.twig.html

For something like that the authoring process in KDL becomes way easier for users to generate, there is a level of abstraction of course because humans will have the "final desired" output in mind. Even if there is no 1:1 i think this may work out.

Things we will need to research (and I will be slow, our backlog of urgent things is large but exploring future ways is also our passion)

• The PHP library is not super fast but clear. The Node parsing looks pretty similar to a native XML parser in PHP already but not sure if I have a fast/and verbose KDL validator there I can use to pre-parse KDL and give users a decent feedback?
• We may need to build a class/wrapper for the current PHP parser
• We need to run tests to make sure which Native KDL expressions are not "parseable" via PHP or are all of them?
• We need to explore size/memory limits. JSON parsing in PHP is quite fast and efficient. I need to compare.

Thanks for your great work on this.