Changes between Initial Version and Version 1 of MapGuideRfc158

Timestamp:

Apr 11, 2017, 8:40:16 AM (7 years ago)

Author:

jng

Comment:

--

MapGuideRfc158

@@ +1 @@
+
+= !MapGuide RFC 158 - Simplified JSON responses and GeoJSON support =
+
+This page contains a change request (RFC) for the !MapGuide Open Source project.
+More !MapGuide RFCs can be found on the [wiki:MapGuideRfcs RFCs] page.
+
+== Status ==
+
+||RFC Template Version||(1.0)||
+||Submission Date||12 Apr 2017||
+||Last Modified||12 Apr 2017||
+||Author||Jackie Ng||
+||RFC Status||draft||
+||Implementation Status||In Progress||
+||Proposed Milestone||3.3||
+||Assigned PSC guide(s)||(when determined)||
+||'''Voting History'''||(vote date)||
+||+1||||
+||+0||||
+||-0||||
+||-1||||
+||no vote|| ||
+
+== Overview ==
+
+This RFC proposes to simplify all JSON responses from the mapagent
+
+== Motivation ==
+
+All JSON responses from the mapagent are verbatim conversions from their XML counterparts. 
+
+However this conversion process results in JSON that is quite cumbersome to consume:
+
+ * All properties are arrays.
+ * All properties are string values.
+ 
+This is due to the conversion process not taking the content model (and its data types/element cardinality) into account, taking the lowest common denominator approach.
+
+== Proposed Solution ==
+
+The MgJsonConvert class that does the actual XML to JSON conversion will be modified to include a hard-coded list of XML element paths:
+
+ * For elements that contain 0 to many elements
+ * For elements that are not string data types
+ 
+During the conversion process, we check the computed XML element path of the element we're converting and check if it is in one of these two lists
+
+ * If it is in the first list, the element is written as a JSON array
+ * If it is in the second list, the element will not have its value quoted
+
+To retain compatibility with clients using the JSON responses of the older mapagent, using simplified JSON responses is opt-in, by including {{{CLEAN=1}}} as part of your mapagent request parameters. 
+When this is specified, the old XML to JSON conversion behaviour will be used.
+
+With the new JSON responses, not only are they more simpler to use (not everything is an array and not everything is a string and the content structure is semantically similar to their XML counterparts), but is also much more compact due to the amount of {{{[}}} and {{{"}}} characters we save by not converting everything to string arrays
+
+Fusion will also be updated to take advantage of the new clean JSON responses.
+
+== GeoJSON output ==
+
+For the {{{SELECTFEATURES}}} mapagent operation, even with the clean JSON response formatting applied, the JSON response is still near-useless for consumption by client applications.
+
+For this particular operation, if we want the response in JSON, since it includes spatial data for features it is more practical to return this in GeoJSON format, which is more ubiquitous and more practical for client-application consumption.
+
+To enable this, we'll be adding a new MgGeoJsonWriter utility class to the PlatformBase library to enable easy GeoJSON conversion from feature readers
+
+{{{
+class MG_PLATFORMBASE_API MgGeoJsonWriter : public MgGuardDisposable
+{
+PUBLISHED_API:
+    MgGeoJsonWriter();
+
+    STRING FeatureToGeoJson(MgFeatureReader* featureReader, MgTransform* transform);
+
+    STRING FeatureToGeoJson(MgReader* reader, MgTransform* transform, CREFSTRING idPropertyName, CREFSTRING geomPropName);
+};
+}}}
+
+The {{{SELECTFEATURES}}} operation with {{{CLEAN=1}}} will use this class to output the response as GeoJSON
+
+== Implications ==
+
+Any time a new schema or schema revision is introduced, this hard-coded list will have to be updated to know which elements in these new schemas require special processing.
+
+== Test Plan ==
+
+Test all applicable mapagent operations with CLEAN=1 to verify clean JSON output.
+
+== Funding / Resources ==
+
+Community