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

["G. Ken Holman" <gkholman@CraneSoftwrights.com>]

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.

> 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.

My opinion on this is captured here:

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

One might observe that the committee bowed to the community 
requesting a JSON serialization of UBL, and the committee delivered 
it ... but no-one I know of is actually using it. No governance would 
permit it. And, technically, the JSON serialization has no UBL 
extension point because of the lack of a JSON schema wild card 
validation constraint.

> 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.

. . . . . . Ken

Disclaimer: take my words with a grain of salt because I am the 
editor of the UBL Standard, the designer of the UBL extension point 
scaffolding, and the author of the UBL JSON serialization. But I 
welcome others to make their observations regarding your post.

At 2021-11-23 21:49 +0000, you wrote:

> William, greetings.
>
> On 23 Nov 2021, at 18:21, William David Velasquez wrote:
>
> > <ext:UBLExtension>
> > <ext:ExtensionContent>
> > <SWMaker>
> > <SWMakerInfo>
> > <Name>FirstName</Name>
> > <Value>Erick</Value>
> > <Name>LastName</Name>
> > <Value>Rich</Value>
> > <Name>SWName</Name>
> > <Value>FancySoft v.1.0</Value>
> > </SWMakerInfo>
> > </SWMaker>
> > </ext:ExtensionContent>
> > </ext:UBLExtension>
> and
>
> > I'm expecting customer won't be open to accept the change, because 
> > the actual structure can do the work.
> >
> > So, what arguments would you use to convince the customer?
> One possible tack is to note that the key-value structure is highly 
> unidiomatic XML, so XML tools will always work poorly with it 
> (you're mentioned a couple of examples of what one might call 
> 'impedance mismatches' already), and it is thus building in 
> technical debt by design.
>
> 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.
> Use JSON instead (cf the discussion on this list in the last few 
> weeks).  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.
>
> If the conclusion is that there are key-value pairs, and this 
> serialisation has got to have pointy brackets in it (kos that's what 
> the kool kidz are doing these days), then potentially use plist format [1].
> I don't think anyone believes that .plist was a good Apple design 
> decision, but there are at least libraries for it, and no-one has to 
> waste their good energies trying to put a different shade of 
> lipstick on this particular pig.
>
> I see that there's at least some 'ext:' XML namespacing happening 
> there, so another one surely wouldn't hurt.
>
> (I don't think <Name>/<Value> is a great design, by the way)
>
> Best wishes,
>
> Norman
>
>
> [1] https://en.wikipedia.org/wiki/Property_list
>
> --
> Norman Gray  :  https://nxg.me.uk
> SUPA School of Physics and Astronomy, University of Glasgow, UK
>
> _______________________________________________________________________
>
> 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

--
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 |