Re:The Rise and Fall of CORBA (2006)
by hyperpallium on Sunday September 13, 2015 @07:27PM
(#10213117)
Rereading, my comment was utterly misleading about "machineless"! I meant no local development. All in the cloud + browser (or another client). So a phone just needs a browser. [see my other reply]
I missed the Barrister IDL-JSON binding... kinda important! I must check how they bind choice/sum/polymorphism to JSON...
2) JSON by example schema: Thanks! It's never been used; the above comment is the only documentation. Maybe I should write a RFC... or at least first draft of a spec. And a reference implementation.
Actually using this schema to validate JSON instances requires using all the fields to determine which branch you have. They can have fields with the same name, provided the entire set is distinct. So these are OK (letters as fieldnames):
{a,x}+{a,y}; {a,b}+{a}; {a}+{} (empty object)
Thinking further, duplicate fields implies a different data model, and most JSON parsers will use a hash. Maybe it would ease adoption to fake up a syntax (eg addr-1, addr-2, addr-3 for the "same" field, with escaping rules for '-'). I wonder wonder about usage: maybe apps don't use this approach (same field can have different kinds/types of values); maybe they use a field for each type, only having a value for one of them? (or an explicit "type" field). It's important to model common practice.
But I think JS coders do use polymorphic behaviour (same method names with different code).
3) Add more primitve types. Thinking further, although people end up wanting more precise primitive types for storing data, if JSON is mainly used for transferring values between languages, it really need only be as expressive as the languages themselves, which generally don't go into details like syntactic nature of primitive values and ranges of integers and lists etc. (They wrap these concepts in objects; JSON can too).
I'm stepping back from the idea - I just liked that you could add richer types without losing the property of looking like JSON - but you do lose the property of representing types with the types of JSON values. Can leave the extra sophistication to xml schema (and json schema) for those who need it. Unless JSON itself add more primitive types (which I doubt!).
PS: one more comment to go. I plan to reread your previous comments on CORBA etc now I have a better idea where you're coming from.
I missed the Barrister IDL-JSON binding... kinda important! I must check how they bind choice/sum/polymorphism to JSON...
2) JSON by example schema: Thanks! It's never been used; the above comment is the only documentation. Maybe I should write a RFC... or at least first draft of a spec. And a reference implementation.
Actually using this schema to validate JSON instances requires using all the fields to determine which branch you have. They can have fields with the same name, provided the entire set is distinct. So these are OK (letters as fieldnames):
Thinking further, duplicate fields implies a different data model, and most JSON parsers will use a hash. Maybe it would ease adoption to fake up a syntax (eg addr-1, addr-2, addr-3 for the "same" field, with escaping rules for '-'). I wonder wonder about usage: maybe apps don't use this approach (same field can have different kinds/types of values); maybe they use a field for each type, only having a value for one of them? (or an explicit "type" field). It's important to model common practice.But I think JS coders do use polymorphic behaviour (same method names with different code).
3) Add more primitve types. Thinking further, although people end up wanting more precise primitive types for storing data, if JSON is mainly used for transferring values between languages, it really need only be as expressive as the languages themselves, which generally don't go into details like syntactic nature of primitive values and ranges of integers and lists etc. (They wrap these concepts in objects; JSON can too).
I'm stepping back from the idea - I just liked that you could add richer types without losing the property of looking like JSON - but you do lose the property of representing types with the types of JSON values. Can leave the extra sophistication to xml schema (and json schema) for those who need it. Unless JSON itself add more primitive types (which I doubt!).
PS: one more comment to go. I plan to reread your previous comments on CORBA etc now I have a better idea where you're coming from.