Thanks everybody for your insightful ideas.
Ken, I'm particularly interested in your opinion because extensibility
should be a very common requirement in UBL implementations.
Do you have knowledge of what other approaches have been used with UBL
for reaching such extensibility?
El 2021-11-23 17:36, G. Ken Holman escribió:
> 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 |
>
>
> _______________________________________________________________________
>
> 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
--
William David Velasquez
Creativo de Software
Creativos Digitales S.A.S.
Tel 311 7098421 - 604 3221730
