Re: [xml-dev] How long before services sending/receiving XML mightneed r

[Stephen D Green <stephengreenubl@gmail.com>]

Hi Ken

Ken wrote:

>The subject line sending/receiving doesn't 
>indicate whether the exchange is happening inside 
>of the computer (coupling programs) or outside of 
>the computer (interchange between information systems).

>. . . . . Ken

My question relates primarily to submissions of data/documents/information to government endpoints. But it could equally relate to how those endpoints receive the data. Or, as with UBL, how data/documents are both sent and received by government and business in exchanges such as with orders, order responses, invoices, etcetera.

Kudos, shout out to UBL for accommodating JSON now in the NDR and doing so directly from CCTS semantic model to JSON. That allows continuity for the UBL business documents, and custom-defined documents using UBL methodology, even if the skillset of developers requires a move in future from XML to JSON.

Of course governments have their own schemas, both XML and JSON with various formats in UK (where I am), and USA with NIEM, and everywhere. But the UBL demonstration of how to directly implement JSON schemas will be helpful.

It would be handy to gauge likely timelines for how governments might be advised to move towards JSON, so that software suppliers might decide how to synchronise this with ongoing plans, if any, for replacements of systems. It seems inevitable to me that eventually skills in XML might be harder and harder to find, and that fashions of software development might move more and more towards primitive code programming away from tooling such as XML tooling. So requiring XML to be sent to government systems and received from government systems might be less and less the norm in coming years. 

All the best

Stephen Green

On Fri, 12 Nov 2021 at 21:58, G. Ken Holman <gkholman@cranesoftwrights.com> wrote:

At 2021-11-12 11:42 -0800, Kurt Cagle wrote:
>JSON is a necessary evil because most
>programmers have been trained to NOT be systemic
>thinkers, but rather to concentrate on their own
>particular module or component. JSON fits this
>mentality well because JSON serializes cleanly
>into _javascript_ objects, and reasonably well into Python objects.

In 2017 I summarized my personal opinion
regarding "most programmers today" using JSON
because it makes their job easier, it doesn't
make the user's job easier when dealing with information exchange:

https://www.linkedin.com/pulse/horses-courses-perspective-xml-vs-json-discussion-ken-holman


TL;DR - JSON is for tight coupling in
programming, XML is for data description in interchange.

The subject line sending/receiving doesn't
indicate whether the exchange is happening inside
of the computer (coupling programs) or outside of
the computer (interchange between information systems).

. . . . . Ken

>  XML has a complex DOM that's more difficult to
> navigate because the W3C assumed that most
> people would choose to use XPath rather than
> the low-level DOM primitives, but XPath
> notation was too different from _javascript_ dot
> notation conceptually, so you STILL have people
> who prefer using DOM (or worse, CSS selectors)
>
>Of course, I'm an information architect, not a
>programmer, so what do I know. :-)
>
>Kurt Cagle
>Community/Managing Editor
>Data Science Central, A TechTarget Property
><mailto:kcagle@techtarget.com>kcagle@techtarget.com
>or <mailto:kurt.cagle@gmail.com>kurt.cagle@gmail.com
>443-837-8725
>
>
>On Fri, Nov 12, 2021 at 8:05 AM Ihe Onwuka
><<mailto:ihe.onwuka@gmail.com>ihe.onwuka@gmail.com> wrote:
>
>On Fri, Nov 12, 2021 at 5:37 AM Peter Flynn
><<mailto:peter@silmaril.ie>peter@silmaril.ie> wrote:
>On 12/11/2021 08:12, Marcus Reichardt wrote:
> > At the risk of sounding pedantic, i don't agree at all with what you
> > said, Mukul ;)
> >
> > [...] XML's other uses - as a preferred payload format for web
> > services, and as go-to language for configuration and other metadata
> > - have been on the decline for about 15 years as well.
>
>Many of these were bandwagons (with the exception of text delivery).
>Very attractive at the time ("Look! Only one format!").
>
>
>What is being overlooked is that  in the
>context of government IT, factors relating to
>the  publishing and SGML heritage of XML are a bit of a red herring.
>Aside from the core use case of contracts and
>validation, XML usage for document exchange in
>government IT derives from it offering schema
>technology that was intentionally designed to
>support object oriented modelling use cases.
>This is explicitly set out in Section 5 below
>which variously and explicitly mentions the
>concepts of class, inheritance and derived types.
>
><https://www.w3.org/TR/NOTE-xml-schema-req>https://www.w3.org/TR/NOTE-xml-schema-req
>
>JSON OTOH was  designed with a set of disjoint
>primitive types and whereas JSON Schema may have
>presented an  opportunity to address
>deficiencies in it's OO modeling capability, it was deliberately not taken.Â
>That people seriously expect to be able to slot
>JSON into a complex modelling use case that it
>was intentionally not designed for is testament
>to the degree of FUD surrounding exactly what JSON  should be used for.Â
>Beyond the noise of JSON advocacy, what else is backing that up?
>


--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/x/ |
Check our site for free XML, XSLT, XSL-FO and UBL developer resources |
Streaming hands-on XSLT/XPath 2 training class @US$125 (5 hours free) |
Essays (UBL, XML, etc.) http://www.linkedin.com/today/author/gkholman |


_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

--

----

Stephen D Green