Comments on: Adding Extensibility to JSON Data Formats http://www.goland.org/jsonignorerule/ Technology, Politics, Food, Finance, etc. Fri, 30 Jul 2010 16:51:19 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Administrator http://www.goland.org/jsonignorerule/comment-page-1/#comment-17767 Administrator Sat, 05 Aug 2006 01:07:56 +0000 #comment-17767 The more I think about this the more I think you're right. Simpler is usually better and extensibility is a pain even in the best case. Besides I don't look forward to explaining the whole array mess. I'd like to get a little more feedback but my guess is that I'll probably just remove the simple value extensibility all together. The more I think about this the more I think you’re right. Simpler is usually better and extensibility is a pain even in the best case. Besides I don’t look forward to explaining the whole array mess. I’d like to get a little more feedback but my guess is that I’ll probably just remove the simple value extensibility all together.

]]> By: Pete Dapkus http://www.goland.org/jsonignorerule/comment-page-1/#comment-17754 Pete Dapkus Fri, 04 Aug 2006 16:17:19 +0000 #comment-17754 I think "processor MUST ignore" is as far as you can go. I know you're making this simple, but even still, it seems like it assumes to much of the processor. If you want people to use your service, you should only expect them to build what they need today. How bad would it be really to ask that service provider use new names for new things and leave the old things alone? I think I'd rather deal with the clutter, especially in the case of simple type. I think most of your examples read better if you just add new fields - you may wonder why there's redundant data, but you won't have trouble understanding the message. I know it's not always possible to know what you will need, but I'd rather put the burden on protocol designers to plan for extensibility. If you think you way want to extend something, make it an object, not a simple value. I think “processor MUST ignore” is as far as you can go. I know you’re making this simple, but even still, it seems like it assumes to much of the processor. If you want people to use your service, you should only expect them to build what they need today.

How bad would it be really to ask that service provider use new names for new things and leave the old things alone? I think I’d rather deal with the clutter, especially in the case of simple type. I think most of your examples read better if you just add new fields – you may wonder why there’s redundant data, but you won’t have trouble understanding the message.

I know it’s not always possible to know what you will need, but I’d rather put the burden on protocol designers to plan for extensibility. If you think you way want to extend something, make it an object, not a simple value.

]]>