Today we have Geode XSD which contains two root elements, cache (server) and client-cache and Native XSD that contains a client-cache. For the most part these two schemas are the same for element client-cache. It strikes me that it makes sense to coalesce these into a single common XSD. For areas that need to diverge, specific to Java, C++ or .NET, the clients would use extension namespaces similar to how the server config does can today.
Consider something like this: <client-cache xmlns="http://geode.apache.io/schema/client" xmlns:java="http://geode.apache.io/schema/client/java" xmlns:cpp="http://geode.apache.io/schema/client/cpp" xmlns:net="http://geode.apache.io/schema/client/net" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://geode.apache.io/schema/client http://geode.apache.io/schema/client/client-1.0.xsd http://geode.apache.io/schema/client/java http://geode.apache.io/schema/client/java/client-java-1.0.xsd http://geode.apache.io/schema/client/cpp http://geode.apache.io/schema/client/cpp/client-cpp-1.0.xsd http://geode.apache.io/schema/client/net http://geode.apache.io/schema/client/net/client-net-1.0.xsd" version="1.0"> <net:appDomain enabled="true" /> <pool name="example-pool" subscription-enabled="true" subscription-redundancy="1"> <java:someJavaSpecificThing name="theJavaWay" /> <cpp:someCppSpecificThing name="theCppWay" /> <net:someDotNetSpecificThing name="the.NETWay" /> <server host="l1" port="1234" /> <server host="l2" port="1234" /> </pool> </client-cache> This config file can now be change controlled by the customer and remain consistent across all clients. This single file can be deployed to all clients regardless of the client implementation language/framework. Thoughts? -Jake