Brian,
I get you.
So in general, there are two ways, it seems to me, to deal with the
impedance mismatch. The first is to work around it with syntactic
elaboration. As you note, this makes ugly results in the target
language. The other is to constrain one's usage in the host language
such that it maps cleanly into the target language. This makes
prettier results, but of course only a subset of the source language
can be used.
The JSON-friendly XML subset you have in mind would enable the second
approach with minimal or no resort to the methods of the first
approach. Of course, there is no single such subset of XML. In the
project I linked to we have one we are working on, but it is not the
only one possible and (depending on your needs and what makes you mad)
possibly not the best.
To get closer to your question, however, it bears mentioning that we
are not thinking about the XML subset (that we are supporting)
explicitly, but rather backing into its definition, by implementing a
schema syntax to produce "equivalent" JSON Schema and XSD together for
"equivalent" data, subject to some definition of equivalence. (This
work was more or less impossible before JSON Schema was available,
which didn't stop people demonstrating that such a relation is
possible in principle. David Lee, G. Ken Holman, H J Rennau, Jonathan
Robie have all done work on this IINM.) Of course it's in this
definition of "equivalent" here that your question lurks. But it's
much easier when it's a design problem than when it's a theoretical
question.
Cheers, Wendell
On Sat, Jul 13, 2019 at 1:36 PM BR Chrisman brchrisman(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Thanks Wendell,
I think this is kind of similar.
Basically, I work with a number of people/groups that are pretty much
JSON-only.
I commonly find the need to take some sort of XML that we've been
using and provide them with an extract of that data in the JSON
format.
While it's not that difficult to convert XML into JSON with XSLT, I've
been wanting to have some of my structures more 'ready to convert'
already.
As Liam mentioned, the reverse can be problematic because JSON may
include XML-excluded characters, but my interests right now are mostly
around "other people need data (currently in XML) that I'm working on,
and I need to make it easier on me to get it to them.
I've evaluated some xml->json conversion stylesheets, but I would
guess some standard like: "If you wind up with *only* this subset of
XML functionality, your XML will always be reasonably and directly
accessible after conversion to JSON." would help me a lot.
Things like:
- no multiple-namespaces (ie, I can have namespaces in my XML, but
they cannot be reasonably expressed in JSON, so anything in any other
namespace will only exist for XML processing tools)
- containers - can I mark up items to explicitly be containers such
that they translate well to JSON arrays? This frustrates me because
XML doesn't require objects of ostensibly the same type (element name)
to be stored in an array, but JSON does (using language loosely here,
hope the meaning is pretty clear)
- attributes vs text nodes... lots of ways to go there.. but perhaps
choosing only one of those is the best option?
- (maybe other stuff)
In essence, I know there's certainly a way to express *any* XML in
JSON, so long as we're willing to go far enough in producing ugly
JSON.... but I've been looking for a standard such that if I express
my XML in 'just such a way', it will provide JSON that ... doesn't
make people angry... :)
- Brian
On Mon, Jun 24, 2019 at 2:25 PM Wendell Piez wapiez(_at_)wendellpiez(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Good readers,
Gerrit points out to me the link was broken. Which is odd, but here's
another one:
https://pages.nist.gov/OSCAL/
Apologies! -- Wendell
On Mon, Jun 24, 2019 at 5:16 PM Wendell Piez
wapiez(_at_)wendellpiez(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Hi,
XML and JSON alignment is one of the problems we've been working on here
www.usnist.gov/OSCAL/
Warning: under development and subject to change. But lots of XSLT in
there!
Cheers, Wendell
On Sat, Jun 22, 2019 at 11:07 PM BR Chrisman
brchrisman(_at_)gmail(_dot_)com
<xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com> wrote:
Has there been any work to define an XML subset which is
simply/directly transformable into JSON?
I know there are many XML expressions that are very difficult to
convert to JSON due to limits in JSON that make such a conversion very
messy, but I would guess that with a number of standardized
restrictions, that might be easier?
Just wondering... I'm seeing more and more situations where I need
that kind of 'more direct compatibility'.
- Brian
--
...Wendell Piez... ...wendell -at- nist -dot- gov...
...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
...github.com/wendellpiez... ...gitlab.coko.foundation/wendell...
--
...Wendell Piez... ...wendell -at- nist -dot- gov...
...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
...github.com/wendellpiez... ...gitlab.coko.foundation/wendell...
--
...Wendell Piez... ...wendell -at- nist -dot- gov...
...wendellpiez.com... ...pellucidliterature.org... ...pausepress.org...
...github.com/wendellpiez... ...gitlab.coko.foundation/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
--~--