I note in the middle of this conversation on support and community that a recent public effort to firm up the interoperability of JSON schemas for complex messages that demand consistent interoperable inter-vendor interpretation got zero comments during its first (and therefor final) public review.
JADN JSON Abstract Data Notation
https://docs.oasis-open.org/openc2/jadn/v1.0/cs01/jadn-v1.0-cs01.html
<sigh />
tc
"A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away."
-Antoine de Saint-Exupery
Toby Considine
TC9, Inc.Phone: (919)619-2104
Chair, OASIS OBIX Technical Committee
Chair, OASIS WS-Calendar Technical Committee
Editor, OASIS Energy Market Information Exchange (EMIX) Editor, OASIS Energy Interoperation
blog: http://www.NewDaedalus.com
From: Ihe Onwuka <ihe.onwuka@gmail.com>
Sent: Sunday, November 14, 2021 2:53 PM
To: stephengreenubl@gmail.com
Cc: XML Developers List <xml-dev@lists.xml.org>
Subject: Re: [xml-dev] How long before services sending/receiving XML might need replacement?
Ok. So you are comfortable recommending that a public sector (or a large complex) enterprise architecture/data model be built on _javascript_'s type system. Right?
On Sun, Nov 14, 2021 at 10:24 AM Stephen D Green <stephengreenubl@gmail.com> wrote:
JSON, it is said, was discovered, not invented. It was already
implicit in _javascript_. So there has never been the opportunity to
align it better with XML because _javascript_ was already defined when
XML was invented. So it seems to me. Correct me if I'm wrong.
----
Stephen D Green
On Sun, 14 Nov 2021 at 15:12, Ihe Onwuka <ihe.onwuka@gmail.com> wrote:
>
> Stephen. JSON is young enough that it could have been defined to be interoperable with XML. Have you never asked why it's inventor and protagonists never did that?
>
> On Sun, Nov 14, 2021 at 9:58 AM Stephen D Green <stephengreenubl@gmail.com> wrote:
>>
>> Thanks Norman,
>>
>> I suppose, from experience of twenty years working with .Net, it is, to my mind, an indicator of atrophy of support for a technology such as XML, when libraries in 2021 are still exactly as they were ten to fifteen years ago. JSON support improves with every major new version of .NET, as we see with incorporation of JSON into the System namespace and improvements in JSON support in the HTTP client. The days when XML had such attention are over. Like an older sibling, there is every reason to be jealous when the new baby is getting all the attention, but now JSON itself is almost the same age as XML and still it gets favouritism. We all know the history of this. But if JSON is getting all the attention despite being only a few years younger than XML, is there something to be done or should we be thinking of an exit strategy? For UBL it has taken 10 years to bring JSON support to a similar level to XML, direct generation from CCTS models according to a standardised specification (on the point of being standardised). That is a good example and maybe other XML business semantic standards and libraries should follow this path, fully specifying how to give JSON the same syntactic role as XML has previously enjoyed as a serialisation of the instance documents for those libraries.
>>
>> Regards
>> Steve
>>
>> On Sun, 14 Nov 2021 at 14:33, Norman Gray <norman.gray@glasgow.ac.uk> wrote:
>>>
>>>
>>> Steve, hello.
>>>
>>> On 14 Nov 2021, at 12:43, Stephen D Green wrote:
>>>
>>> > But if you try creating some XML with .NET
>>> > libraries then simply changing from UTF 8 to UTF 16 you should realise how
>>> > poorly these libraries work and how many ridiculous hoops you have to jump
>>> > through to avoid memory leaks. It is simply a matter of curtailed
>>> > investment, still stuck with original DOM-based processing.
>>>
>>> Right, I see what you mean, I think. I've been in that general situation before, but to me, it just sounds like some rather bad tooling (I'm partly echoing Ihe's response here). I'd have hoped that the XML-wrangling and the serialisation would be sufficiently orthogonal that the XML-wrangling (which doesn't care about encoding) would simply send string to the serialiser, and it would worry about encoding them into bytes. Fiddly to set up, but not a hard problem.
>>>
>>> > You then get to see how immature these
>>> > libraries are and how little investment has been made in getting them to
>>> > work with each other and improving them with time. They are stuck in 2005.
>>>
>>> I think it's quite possible that the batteries-included XML support in ecosystems such as .NET hasn't had much TLC in the last decade. It might be that that support was good enough for the 'XML for everything' attitude that was regrettably common around then, but that anyone doing XML 'seriously' would either use (commercial?) third-party frameworks or just learn to live with it, and that this has meant that that batteries-included support has never really got better. I make this remark with some diffidence: I'm not sure how true it is.
>>>
>>> So I probably agree with you, Steve, to the extent that wrangling XML does still feel rather clumsy in most languages. But I don't think it follows that XML is past its sell-by date (which I think is what you're basically suggesting?), since the sort of problems where XML is the right answer (which do not obviously include cases where the goal is sending very simple messages about), are ones where a bit of clumsiness in the serialisation is lost in the noise.
>>>
>>> Parenthetically, it occurs to me that 'encodings' is becoming less of a headache than it used to be, simply because UTF-8 is becoming more ubiquitous.
>>>
>>> Best wishes,
>>>
>>> Norman
>>>
>>>
>>> --
>>> Norman Gray : https://nxg.me.uk
>>> SUPA School of Physics and Astronomy, University of Glasgow, UK
>>
>> --
>> ----
>> Stephen D Green