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