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

[Norman Gray <norman.gray@glasgow.ac.uk>]

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


-- 
Norman Gray  :  https://nxg.me.uk
SUPA School of Physics and Astronomy, University of Glasgow, UK