I'm looking for a configuration file format with a schema. Something simple like YAML, but has a schema like XSD does for XML. Does this exist?
XML is a better serialization format than it is a configuration format but combined with XSD, it makes a powerful self-documenting configuration format.
Thanks!
One answer is Config4*. I recommend you read Chapter 2 (overview of the configuration syntax) and Chapter 3 (overview of the C++/Java API and overview of the schema language) of the Config4* Getting Started Guide to learn enough to decide if it suits your needs. Disclosure: I developed Config4*.
Another answer is Json, which now has its own schema language. I haven't used it, so I can't comment on its merits.
Related
I'm asking about the reason for using YAML for package managing pubspec.yaml in Dart, why did they choose YAML, not JSON? what is the unique thing in YAML that makes it a favourite for this purpose instead of another?
In my opinion:
1. Readability
YAML is much better... Like Python
2. Commentary
In JSON you can't give comments
For flutter/Dart application maintenance, of course requires comments since the PUBSPEC file was created.
3. Speed
Indeed JSON files are smaller and faster, but for cross-platform developers, more emphasis on ease of reading and speed of production. Moreover, the development of mobile hardware is now very good.
4. Complexity
JSON structure is simpler, so it does not support complex configurations.
But, YAML... be aware that "white space" (tabs v spaces) matters.
What is the difference between YAML and JSON?
Most importantly support for comments & Better readability
The design goal of JSON is to be as simple as possible and be universally usable. This has reduced the readability of the data, to some extent. In contrast, the design goal of YAML is to provide a good human-readable format and provide support for serializing arbitrary native data structures.
Source: JSON vs. YAML: A Dive Into 2 Popular Data Serialization Languages
I came across this service from stackoverflow
https://api.stackexchange.com/2.3/questions?fromdate=1519862400&todate=1522368000&order=desc&sort=activity&site=stackoverflow&tagged=python
I believe the source is from a database. How do I build an Xml to spit me out data in similar format?
I use the below logical lines
xmldoc.Load(xmlFileName);
Newtonsoft.Json.JsonConver.SerializeXmlNode(xmldoc);
Any recommendation of how to build the Xml which is a reverse process? My solutions are heavily dependant on Xml and flatFiles
According to https://api.stackexchange.com/docs the StackExchange API only supports JSON output, not XML. So you will have to convert the JSON to XML.
My own preference is to do this conversion "by hand" using XSLT 3.0 rather than using a standard library, because standard libraries often give you XML that's rather difficult to work with.
Is there a tool like Google's Protobuf for JSON? I know you can convert from a Protobuf format to JSON but that requires a whole lot of extra serialization/deserialization, and I was wondering if there is some kind of tool that lets you specify the structure of a JSON message and then automatically generates libraries for use in a specified language (direct serialization/deserialization not just a wrapper around Protobuf's JSON formatter class)
I know nearly all languages provide their own in house way of handling JSON, and many higher level ones even allow you to avoid the boiler plate parsing code, but I was looking for a universal tool where you would only need to specify the format once, and then just get the generated libraries for use in multiple languages.
The Protobuf equivalent would be JSON-Schema, but still is language dependent on having a serializer or code generator available, just as Protobuf is.
If you're looking at making a REST-API, then OpenAPI Spec + swagger-codegen could be an option.
So i have started to work with conversion from XML or JSON to Edifact (EDI), and i have no idea where to begin. i have started to read a bit about edifact and i thought id post a question here to maybe get some pointers of what is good to know and also maybe of some links and places to start learning about conversion to edifact.
So i have started with trying to convert XML to Edifact and soon realized that i would need an XSD for that. And i thought If Edifact is a pretty tightly kept standard, is there any already existing XSDs for Edifact 911 ORDERS and also DESADV. I couldn't find any.
Any information would be helpful at this moment. Thank you!
I don't think you'll find any schemas that aren't proprietary to a translation package. Any schema would probably be a generic representation of the standard, and not specific to your implementation, or your trading partner's guidelines.
Your XML / JSON is proprietary to you (or your ERP). So you'll need to take the XML tags or JSON objects and convert them into the segment/element enveloped structure of the EDIFACT document. BOTS might be able to help you here, as it is open source (Python, I think). Outside of that, there are really great drag/drop mapping tools out there that will allow you to solve your problem.
Following is my requirement:
Application A is creating a JSON based on its Java Beans and sending to my Application.
I have to take this JSON and convert it into XML (XSD for this is completely different than my JSON structure) and send to Application B.
Solution 1) I am currently converting this json to xml using json.org library.Then using Apache-xalan and XSL stylesheet, I am converting this to xml format as required by App B.
Solution 2) Converting this json to Java Bean (JB1).Then converting this JB1 to another Java Bean (JB2) as per the xml structure required by Application B.Then convert JB2 to XML for app B.
Solution 3) Using Apache Xalan and Xerces to parse through the input json and make the XML in Java itself without using XSL.
Which is better approach (in simplicity of code, throughput )? As JSON becomes more complex, is it easy to use solution 1 ? Please suggest if there is better approach other than these 3 ?
XSLT 3.0 offers a built-in json-to-xml() function. Once you have the XML, you can easily transform it to your required format. It is implemented in Saxon 9.7 (PE or higher) and I believe in Exselt.
Solution 1: Yes. This is the conventional and best path for both simple and complex JSON and simple or complex targeted XML.
Solution 2: No. There's no reason to introduce Java Beans as an intermediate form, especially if you have no other need for Java Beans. This option unnecessarily introduces transformational and marshalling complexity.
Solution 3: No. Neither Xalan nor Xerces are designed to parse JSON; they are designed to parse XML.
There are sample programs that will map a JSON document into an equivalent XML document and back; I wrote one as a demo for Liberty's support of json-p (javax.json), using an XML vocabulary I called JinX (JSON in XML). That could be used as a pre/post processor wrapped around XSLT, if desired.
Better solutions are possible -- redefine XSLT to operate on JSON trees, for example -- but would take a bit more work.
JSON is, pure-and-simple, "a communications protocol." In other words, "it specifically exists(!) to allow 'arbitrary (JavaScript) data structures' to be conveyed between some-client and some-host," over "the HTTP(S) protocol."
Therefore: "it is not(!) XML," and therefore must never be considered to be "appropriate input to XSLT!"
"Thou shalt not mix Apples and Oranges!"
If you wish to apply "XSLT" technologies to a "JSON-derived" input (which is, by definition, "a data structure ...") then you must first, and "by whatever suitable means," convert that data structure into XML.