Re: XSLT code for XML to JSON conversion?

Many thanks to all for some excellent input on this topic. We will explore

1. Some of the converters.
2. Sending XML to the client, and letting Javascript do the conversion 
to the DOM

BTW, the XML we are using is the ISO-19115-2 (19139) schema:
https://www.iso.org/obp/ui/
https://data.noaa.gov/resources/iso19139/

Regards,
--Rich



On 12/13/19 10:28 AM, Piez, Wendell A. (Fed) wendell.piez@xxxxxxxx wrote:
>
> I think itbs fair to say there will be no absolutely generic 
> XML<->JSON alignment tool or even approach. This is because there is 
> no such thing as bgenericb XML or JSON, there is only the actual XML 
> and actual JSON you actually have or need. As Mike says, the stuff you 
> get from the churner you find on the Internet just isnbt good enough 
> to use.
>
> That being said, there is a broad need, and this is a research area 
> (see for example 
> https://www.balisage.net/Proceedings/topics/JSON.html) and projects 
> are working on it including the one I am involved with these days 
> (https://pages.nist.gov/OSCAL/) b&
>
> b& which may not be much use to you inasmuch as it is so 
> domain-specific. Our approach is to produce lossless bidirectional 
> converters, tailored for a particular application (tag set) from a 
> common metaschema source that bridges the expressive differences 
> between the two data models. This entails making certain concessions 
> regarding the modeling, for example, of arbitrary mixed content. This 
> is something that our domain permits us to do. (bHunks of proseb are 
> relatively easy to tame and manage in our world, at least compared 
> with some kinds of data and applications, and where they are not, 
> there are other standards that can be brought in to help bridge). The 
> flip side is, we can be much more aggressive than most XML-based 
> documentary description formats with respect to optimizing both syntax 
> and model on both sides (i.e., as XML tree of elements vs JSON or YAML 
> objects/properties).
>
> I would say the first question to ask in pondering a conversion 
> pathway is, how much of your XML is data-like, vs how much of it is 
> bsoupyb documentary data? In particular, do you have any content 
> models of the form (a | b)*, which is impossible to represent in JSON 
> without arrays? Note this family of element structures includes text 
> mixed with bold, italics, and anchors represented as elements. (Note 
> that recursive models are not a problem b while maintaining sequence 
> among sibling nodes, is.)
>
> Where there are stretches of mixed element or mixed element-and-text 
> content, you first of all need a strategy for how that will be dealt 
> with in the JSON. Without that there is nothing that can be done.
>
> If there are not b if your XML or most of it is already nice and tidy 
> and data-like, or if you are starting on the up hill side (with the 
> JSON object model) b then it becomes more conceivable as a mapping 
> exercise.
>
> In either case, starting with a good idea (holistic and comprehensive) 
> of what the JSON would look like b given the requirements of the data 
> -- is necessary.
>
> My guess is that there is much experience on this list that might 
> speak to all this, were it not such an octopus of a topic.
>
> FWIW b the XSLT + XPath 3.1 pathway *does* work. But it is not generic.
>
> Cheers, Wendell