Re: [xml-dev] Help with XML anti pattern

["G. Ken Holman" <g.ken.holman@gmail.com>]

At 2021-11-24 19:25 +0000, Norman Gray wrote:
> Ken and all, hello.
Hi!

> On 23 Nov 2021, at 22:36, G. Ken Holman wrote:
> >  So the original poster is obliged to use XML and is asking for 
> the best way to use the XML. I believe the original poster is not 
> asking for alternative serialization syntaxes.
>
> Fair enough -- I take that general point, and I'm not permanently as 
> bad-tempered as I might have seemed in that message.  I hadn't 
> really noticed the 'UBL' in the original query: I don't really know 
> what UBL is, beyond what I see in the Wikipedia page, but I 
> appreciate that this is an important part of the context here.
In the last 15 years more and more business networks exchanging 
procurement information are using UBL. In particular, a number of 
4-corner-model networks of trading partners using network 
representatives have standardized on the use of UBL between the 
network representatives (the trading partners can use any format they 
wish with their own network representative).

In the latest release of UBL 2.3, 91 different document types for 
procurement (e.g. invoice, purchase order, etc.) and 
transportation/logistics (e.g. transportations status, transportation 
execution plan, etc.) are standardized. These are 91 onion skins 
around a common library.

But the UBL committee cannot anticipate everyone's needs and doesn't 
try to. I added the extension point mechanism so that communities 
have a home where they can put what is missing from UBL for them.

> I take it that the UBL spec provides the 'UBL extension point' as 
> basically a black box, which allows participants to pass data back 
> and forth, under some rules they mutually agree.
Precisely!

> Or is the <name>/<value> structure mandated or otherwise specified by UBL?
No, not at all. It is free game under an extension point. But we 
cannot prevent users from making bad decisions in what they put under 
the scaffolding.

Though we do insist (but cannot enforce) that the extension point not 
be used for any semantic concept expressed elsewhere in UBL. It 
cannot be used when one is lazy to find the existing semantic.

> I'm not a great fan of JSON as such.  It's good for quick and dirty 
> information exchange, in a context where both sides are comfortable 
> with looks/walks/quacks-style validation *cough*.
Exactly! Which is not the case when trading partners are exchanging 
from dissimilar systems an invoice demand for payment across 
international borders.

> I'm sure someone's about to say that there are JSON schemas, etc, 
> but my fairly firm impression is that JSON is a nice syntax which is 
> easy to use but which runs out of steam quite quickly.
>
> The problem with name/value XML is that it seems to me that it's XML 
> trying to be JSON -- not pretty.
Agreed.

> William's original request was, it seemed to me: how do I argue 
> against this?  That it's unidiomatic XML, and thus building in 
> technical debt, is the argument I would make in that circumstance.
I like the turn of phrase "it's unidiomatic XML". William, can you 
use this concise argument with your client?

> ...but I'm not sure I'd have much optimism about my winning the 
> argument.  I've been involved in similar arguments in the past, and 
> 'let's just be pragmatic' is an 'argument' that floats to the 
> surface before long (oooh, lookeee... I'm getting bad-tempered again).
Sometimes pragmatism is short sighted.

Thanks, Norman!

. . . . Ken


Ken and all, hello.

On 23 Nov 2021, at 22:36, G. Ken Holman wrote:

> Norman, I agree XML is not appropriate for name/value pairs, but I 
worry your criticisms are misplaced.
>
>> If the context is such that there is a set of key-value pairs 
being serialised in this way, for in-principle arbitrary keys, then 
the conclusion may be that XML is a poor way of doing this serialisation.
>
>  Rather, name/value pairs are a poor choice of information 
representation when using XML.
>
>  The requirement to use UBL ISO/IEC 19845 XML is not a "choice for 
the serialization of name/value pairs" but is imposed in many 
jurisdictions worldwide for the arm's-length exchange of serialized 
semantic business objects of information between trading partners. 
The governance of the international networks mandating UBL would not 
and do not consider JSON as fit for purpose.
>
>  So the original poster is obliged to use XML and is asking for 
the best way to use the XML. I believe the original poster is not 
asking for alternative serialization syntaxes.

Fair enough -- I take that general point, and I'm not permanently as 
bad-tempered as I might have seemed in that message.  I hadn't really 
noticed the 'UBL' in the original query: I don't really know what UBL 
is, beyond what I see in the Wikipedia page, but I appreciate that 
this is an important part of the context here.

I take it that the UBL spec provides the 'UBL extension point' as 
basically a black box, which allows participants to pass data back 
and forth, under some rules they mutually agree.  Or is the 
<name>/<value> structure mandated or otherwise specified by UBL?

>> Use JSON instead (cf the discussion on this list in the last few weeks).
>
>  I believe JSON is inappropriate for arm's-length international 
semantic content interchange and belongs only in tight bindings 
within systems that are entirely under the control of the programmer.
>
>  UBL is used between disparate systems, with different internal 
representations of the semantic content, and so XML is the ideal 
syntax for bridging those systems. XML imposes no internal memory 
representation of the content because users process the XML and 
populate their own choices of internal representation.

I'm not a great fan of JSON as such.  It's good for quick and dirty 
information exchange, in a context where both sides are comfortable 
with looks/walks/quacks-style validation *cough*.  I'm sure someone's 
about to say that there are JSON schemas, etc, but my fairly firm 
impression is that JSON is a nice syntax which is easy to use but 
which runs out of steam quite quickly.

The problem with name/value XML is that it seems to me that it's XML 
trying to be JSON -- not pretty.

William's original request was, it seemed to me: how do I argue 
against this?  That it's unidiomatic XML, and thus building in 
technical debt, is the argument I would make in that circumstance.

...but I'm not sure I'd have much optimism about my winning the 
argument.  I've been involved in similar arguments in the past, and 
'let's just be pragmatic' is an 'argument' that floats to the surface 
before long (oooh, lookeee... I'm getting bad-tempered again).

>> I think this is quite a good example of XML not being the right 
answer for every problem, and indeed this is the sort of solution 
that gives XML a bad name.
>
>  I feel your conclusion is misplaced.
>
>  The UBL extension point scaffolding is designed for containing 
the XML representation of semantic content not standardized by the 
UBL committee. It is up to users to choose what structures to put 
into the UBL extension point as it is out of scope for the UBL 
committee. I hate when it is used poorly, but the committee created 
it for open use by users and this is good evidence of it being used 
poorly. And so I worry your conclusion is focused on the use of XML 
syntax being a bad choice rather than the use of structures chosen 
within the XML being a bad choice. The bad information design 
shouldn't govern the syntax choice ... the design should be fixed.
>
>  I would rephrase your paragraph as: I think this is quite a good 
example of a poorly-chosen structure for the given syntax serialization.

There's a lot in this paragraph, and I think I'd agree with a large 
fraction of it.

I _certainly_ agree that the structure of the information is more 
important than a particular serialisation.  A key-value structure is, 
I'd lay money, going to cause pain before too long, and putting it in 
pointy brackets doesn't make that suddenly a good serialisation (I'm 
sure no-one here would imagine it did, but I suspect some of 
William's interlocutors might, if not quite in that language).

Even RDF/XML would be a better choice, and I have a love-hate 
relationship with that.

Thanks for responding to my comments so thoughtfully.

Best wishes,

Norman

--
Contact info, blog, articles, etc. http://www.CraneSoftwrights.com/m/ |
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 |