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
