However, with 'id' right now, one would assume that far more often it
will only serve to prevent the most obvious, concise, common and
simple means of providing existing unique object identifiers as a
field in a JSON schema (ie. using 'id' as a field providing the
primary identifier for some object from some backend database).
I suggest removing 'id' as and replacing it with '$self'.
This is unlikely to cause naming conflicts as it is out of
conventional namespace.
(Not sure what the formal significance of '$' was for '$ref', but I
see this as partly related functionality.)
- Walter
Erp. Actually just waking up and realised it's a level above
properties. But even then, it seems like rather than aligning the
naming of each it may be useful to include '$' as a prefix for all
aspects of a JSON Schema structure not directly describing a physical
property of the described structure in order to clearly delineate
them.
What was the rationale behind the use of '$' in some contexts,
originally? Only to delineate physical references from
meta-references within the properties portion of the JSON Schema?
Does anyone else feel it will increase conceptual clarity to prefix
everything non-physical within any JSON Schema document (properties,
links, type, format, etc.)?
- Walter
No idea why the $ made its appearance at all, but your suggestion
makes sense. If not $self, then at least $id would be a good idea.
--
Francis Galiegue, fgal...@gmail.com
"It seems obvious [...] that at least some 'business intelligence'
tools invest so much intelligence on the business side that they have
nothing left for generating SQL queries" (Stéphane Faroult, in "The
Art of SQL", ISBN 0-596-00894-5)