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(_dot_)piez(_at_)nist(_dot_)gov wrote:
I think it’s 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 “generic” 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 isn’t 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/) …
… 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. (‘Hunks of prose’ 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
“soupy” 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 – 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 – 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) – 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 – 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 – the XSLT + XPath 3.1 pathway *does* work. But it is not generic.
Cheers, Wendell
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--