Very good advice. I did know that XML support was built-in to Unidata,
and apparently JSON support is included in the newest version of Unidata.
I guess I am leaning towards JSON because as Aaron Titus pointed out, it
is more lightweight than XML.
Charles Shaffer
Senior Analyst
NTN-Bower Corporation
From: "Tony Gravagno" <3xk547...@sneakemail.com>
To: u2-users@listserver.u2ug.org,
Date: 08/02/2013 01:05 PM
Subject: Re: [U2] XML or JSON converter for Unibasic
Sent by: u2-users-boun...@listserver.u2ug.org
I do this sort of thing all the time. I'm also curious to know if a
Uni-query can be rendered directly as XML or JSON. I know QM can
render as XML with a simple modifier on the command-line, thought U2
could do this too. JSON is a different animal and I'm not aware of any
decent JSON builders for any MV environment - they're all proprietary
and unpublished except for the new one in Unidata.
The real problem with all of these XML/JSON solutions is that the
output we get from our reports is 2-dimensional columns and rows - a
curious anomaly after all of these years, considering how much we
pride ourselves on being multi-dimensional. XML and JSON aren't of
much use with flat data. Coding a 2D export to XML or JSON is trivial.
Where this gets complex is in nested relationships, XML and JSON excel
in representation of multi-dimensional data, and again, none of the MV
platforms have rushed to provide decent rendering in this area.
(Except maybe TigerLogic which has built a rich XML server around the
D3 core, like DataStage was built around Universe.)
In plain terms, a U2 report will have something like:
ORD# SHIP.ADDR SHIP.CITY ...
ORD# SHIP.ADDR SHIP.CITY ...
That's 2D. But when you're passing data to another environment, it
expects 3D:
<order>
<id>123</id>
<shipto>
<addr>...</addr>
<city>...</city>
</shipto>
</order>
JSON is exactly the same as XML in structure, just different in
syntax. Part of the problem is that the output here needs to use names
which are acceptable in XML/JSON tags. That might come from the dict
item, probably not unless you have custom dict items just for this.
The way this is usually done is with metadata stored in the dict item
or somewhere else. So you'll have a dict item named ORD#, the
description might say "Order ID" but the "node name" will be "id".
Note above that I'm using <id>123</id>. But that could have been done
like this:
<order id="123">
The issue here is that there is no schema definition that defines
whether you use elements (unique nodes) or attributes (id="123")
within elements. Hardcoded general-purpose solutions will work for
your internal purposes but they won't work as a general solution for
exchanging data with other entities.
And let's not even get into namespaces.
In summary, the above explains why it's tough to have a
general-purpose solution for rendering query output as XML or JSON. A
lot of other metadata is required in order to describe what the
document will look like. The only recourse we have is to use the XML
hooks provided in the DBMS, to hard-code on a case-by-case basis, or
to export and let some external tool do the formatting ... but in all
cases you still need to provide metadata or none of these tools will
know whether to use "id" or "ordnum", or whether to use elements or
attributes.
All of that said, the nature of my business is to create solutions to
problems like this. I'll be happy to do so for any company that
associates value with such solutions.
HTH
Tony Gravagno
Nebula Research and Development
TG@ remove.pleaseNebula-RnD.com
http://Nebula-RnD.com/blog
Visit http://PickWiki.com! Contribute!
http://Twitter.com/TonyGravagno
http://groups.google.com/group/mvdbms
https://bitbucket.org/foss4mv/nebulaware
> From: Charles_Shaffer
> I am looking for a way to send the output of a Unidata data query in
> Unibasic back to a web server (PHP) for building web pages.
>
> Up until now I have used a proprietary method (LF, HTAB, etc.), but
I
> would like to simplify/standardize the method. Seems like this
could
> be done with XML, or JSON or "something I don't know about." Has
> anyone had experience with this and could you offer some advice?
>
> Hoping for a simple subroutine approach as opposed to a
> comprehensive commercial package. Management here is very "price
> sensitive." When I say price sensitive, I mean that if it costs
anything,
> they get their panties all in a bunch. A few hundred dollars might
be
> sellable, a few thousand would not be.
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
--
This email was Virus checked by UTM 9. http://www.astaro.com
_______________________________________________
U2-Users mailing list
U2-Users@listserver.u2ug.org
http://listserver.u2ug.org/mailman/listinfo/u2-users
