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