Change JSON Pointer Fragment use Dot Instead?

[Kyle Lahnakoski2]

Good day!  

It seems a mistake was made! :) I noticed JSON Schema spec requires property access to use forward slash (`/`): `{"$ref": "#person/address/city"}`.  Using dot (`.`) would make more sense:

1. Javascript uses dot notation for accessing properties: `a = person.address.city;`.  So does C++, Java, Python, C#, and a few others.  Having yet-another-way-to-access-properties is entropy we can do without.
2. Uniformity in property access across languages allows us to pipe the fragment string into existing deep-accessor functions: eg [5].
2. JSON document stores, like MongoDB [1]  and Elasticsearch [2], use the same dot notation to refer to inner object properties
3. Some JSON configuration files use dot notation to refer deep inner properties: eg `{"cluster.routing.allocation.awareness.attributes": "zone"}`, Yaml files are the same.
4. Using a character distinct different from the URI path separator improves visual clarity:  eg `///some/path#/person/address/city` makes it easy to miss the `#`.  Missing the hash in `///some/path#person.address.city` will give the reader an opportunity to recover the original.   

I found a conversation in 2012 [3]:  Both sides of the argument are unsatisfying: The advantage to use `eval()` is weak, but so is the argument that `/` is language agnostic (dots can be agnostic).

Can I propose JSON Schema's fragment use dot notation?   Knowing about JSON Pointer [4], am I just too late to change this mistake?  Can someone appeal to a sense of history, or some overall objective, or some mind-state of the IETF, that would make using slash (`/`) more appealing than dot (`.`)?  


Thank you



[1] https://docs.mongodb.org/manual/core/document/#document-dot-notation
[2] https://www.elastic.co/blog/managing-relations-inside-elasticsearch
[3] https://groups.google.com/forum/#!topic/json-schema/cFdEdDkStH0
[4] https://tools.ietf.org/html/rfc6901
[5] https://www.npmjs.com/package/deep-property