tabatkins
commented
10 months ago Sure, you can write JSON or XML into a string. That loses you all the benefits of JSON and XML (it can't be interpreted by readers of either language, since it's in a KDL document) and all the benefits of KDL (all you've got is a node with a big string in it, zero structure).
The point of XiK and JiK is to allow you to store and manipulate KDL documents, and be able to trivially transform them into XML or JSON when needed, because your toolchain takes in one of those languages instead of KDL.
If you don't need that ability - if you're never storing a value that will eventually need to become XML or JSON, or you're fine with doing bespoke translation work from a KDL tree to those languages - then you can write a KDL document optimized for KDL and live your best life.
(why not YAML, SDLang or any other description language that can be contained in an utf8 string and even binary format since KDL includes the base64 format, in other words practically everything).
YAML and SDLang are both vastly less common as input or wire formats; they're almost exclusively used for the same purpose as KDL is meant for: writing a config file. It's much, much less likely that you'll need to put something in your KDL doc that will later need to be converted to YAML.
Similarly, since you also mention the possiblity of encoding KDL in JSON or XML (KiJ/KiX), the same argument applies; it's exceedingly unlikely for that to be a need for users. (And, as both are significantly less expressive, it would in fact be significantly more difficult to do than what JiK and XiK are able to accomplish. It absolutely would not be possible with a relatively "natural" syntax in either language.)
(why freaking 'microsyntax' inside main syntax and not directly real syntax ?)
I'm not sure what you mean by this, and I'm slightly unsure if you understand what's meant by "microsyntax" there. A JiK or XiK document (or subtree) is still just normal KDL; we just impose some restrictions on exactly what kind of KDL you are allowed to write, so that we have a predictable way to transform it. If you ignore those restrictions you still have normal KDL, it just doesn't conform to the JiK/XiK definition and will be rejected by a (compliant) tool.
Overall, I'm not quite sure what your issue actually is. If you don't like JiK/XiK, that's fine; there's no need for you to use them. You don't seem to be raising any actual issues with either of the syntaxes, just a vague unease with the existence of the syntaxes in general. Are there any specific issues you have?
rsz44
Hello,
I hope I'm not duplicating anything here, but first of all I'd like to thank all the volunteers who worked on this great language ( and this is not a duplicate ;) )! KDL is truly original, unique and in its place as a description language that deserves more adoption! Sincerely, I hope to see KDL more often in places where XML stings the eyes today.
I've only recently discovered this language, but I note that it includes a kind of JSON/KDL and XML/KDL interoperability via the JiK and Xik specifications. I think I understand where this is coming from, but I fully agree with @zkat's comment on this subject.
In fact, I wonder why XiK and Jik are defined (and especially in a partial way). Because both notes are in fact brief descriptions (called "microsyntax"). In other words, they're about how KDL can be used to transcribe data into JSON or XML with a 'standardised microsyntax' and implementation, not about real interoperability. In my opinion, this can only deserve the original language. Because there's nothing simpler today than interpreting JSON or XML directly.
In principle, it's a good idea to think about it and to propose a solution for those who want to transfer their data quickly and easily. It also proves that KDL is malleable and a good demonstration. This base remains interesting but in its realization, this is too complicated for not much gains. However, the very nature of the language, in its paradigm, makes it special (and strong) and there is no direct equivalent to JSON or XML. That's why we end up with this somewhat hybrid syntax that's untethered from the KDL language. I find crossing languages with similar properties is somewhat confusing.
In fact, KDL includes almost this possibility: JSON data could simply be written in string directly with a corresponding prefix
mynode value=(json)'{ "a":true }', the same goes for XML. I'm not saying, however, that (json) and (xml) should be included as mandatory 'types annotations' in implementations managed by the KDL specification. This could be an option in parser implementations. Because it seems pointless in this case to limit it to these languages alone (why not YAML, SDLang or any other description language that can be contained in an utf8 string and even binary format since KDL includes thebase64format, in other words practically everything)... It should simply follow naturally that a string annotated withjsonis interpretable as json. Having a kind of built-in, 'configurable' typing is, in my opinion, the whole advantage of KDL. Putting just about anything in it remains an advantage, restrict the possible interpretations of typing annotation as it done with XML-derived languages with attributes, is perhaps not the solution and everyone should be able to decide how to interpret it. Well, KDL can describe an XML or JSON document 'as-is' and doesn't require any additional specification / plugins like JiK and Xik !What is done in these notes is a correspondence written in KDL, which seems a little strange to me in the sense that the language is a fortiori interpreted and that the solution evoked above could be quite suffisant to implement this principle at low cost without unnecessarily complicating the original syntax with additional specifications (why freaking 'microsyntax' inside main syntax and not directly real syntax ? Like shell comands in the main example on the website). The problem with these microsyntax is to lose readability and this makes the KDL syntax more complex (doing as mentioned would just lose readability only if you don't know XML or JSON, which seems unlikely today...). Moreover, this needs specific implementations in any case : either rely on a proven XML/JSON parser, or on additional JIK/XiK interpreter which is an additional parser option and depends on an additional specification of a relatively new language. It doesn't really make sense and I think the choice can be made quickly.
Conversely, the structure of a KDL document is close enough to both languages to be written with them without too many rules, but it needs to be defined beforehand and this is not included in the notes quoted and yet on the subject (only one way seems to be proposed here, e-g KiJ and KiX doesn't exists in JSON / XML specifications and that doesn't make ithem bad languages ;) ).
In any case, it remains a detail, but I find it confusing, a bit pointless and almost counter-productive for the real 'problem' which is that KDL is NOT JSON or XML, but a unique language that has no direct equivalent in these formats which can however contain them. For my part, I'd use the format mentioned (if I ever needed it...) and this will always be subjective to each implementation and/or document.