CLF next: XML or JSON?

tech-engineering
lmt
look-transforms
Tags: #<Tag:0x00007f3c67978538> #<Tag:0x00007f3c679782e0> #<Tag:0x00007f3c67978060>

(Walter Arrighetti) #1

@jim_houston quickly hinted as to JSON being considered a possible replacement to XML for CLF. Although I am a big fan of XML, I think there’s plenty of space to debate on this, as more and more processes (particularly real-time ones) do work with JSON and its streaming version, JWT (JSON Web Token).
I think this deserves a thread here as well.


Notice of Meeting - CLF Spec / Code Review - 1/17/19 9am pst
(Greg Cotten) #2

I think you may have joined the call after the discussion - it seems there is some dissent to changing the format due to significant implementations already supporting XML.

This is more of an implementation detail, but I would imagine any realtime communication of LUTs (between a laptop and a LUT box, for example) would be packaging the data into an intermediate efficient binary format anyway - like a protocol buffer or JWT.


(JD Vandenberg) #3

Thanks for stating this thread @walter.arrighetti. There was a pretty unanimous consensus to stay with XML. Two main reasons:

  1. Let’s not fix what is not broken
  2. There isn’t another file format which offers a compelling enough feature to justify that change.
    Now, please everyone prove me wrong.
    @walter.arrighetti a streaming version is interesting (I don’t know much about it), but I would let this feature to the manufacturer to implement.

(Thomas Mansencal) #4

XML is generally considered to be a better markup language than JSON albeit being very wordy. XQuery/XPath is super powerful to traverse the node tree and available in most of the programming languages.

Tempted to say that for something complex and future-proof like CLF it is a better choice even though I really like JSON.


(Alex Forsythe) #5

This is probably an antiquated request at this point but worth noting to complete the discussion. Originally some had requested a LUT format not based on a markup language so no interpretation would be required. The major obvious con here is that it severely limits the flexibility of what can be carrried in the format. I’m not sure if there’s anyone still arguing for this but it’s worth noting it was requested at one point.