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: firstname.lastname@example.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