Reason for properties beeing an object

已查看 46 次
跳至第一个未读帖子

Simon Heimler

未读,
2015年5月11日 09:53:402015/5/11
收件人 json-...@googlegroups.com
Hello,

this is not a request, just my thoughts on the properties attribute and it beeing an object.

This does cause some troubles for me in those cases where JSON Schema is not used for validation only.

JavaScript Objects do not have an order and the JavaScript VM may shuffle it up as it likes. 
The only way to ensure the order of the properties is through a custom "propertyOrder" array and a custom implementation / logic that always iterates over that array instead of the object.

The property key name is also somewhat duplicated to the id of the object.

Wouldn't it have been easier (and more according to the nature of JavaScript Objects vs. Arrays if properties were an array?

Here's a gist, with two examples: https://gist.github.com/Fannon/1052577fe58b347798b7

I don't want to question the current standard, changing this would definately break backward compatibility.
But I'd like to hear your thoughts on it.

(I'm using JSON Schema for MDE purposes)

Best,
Simon

Pete Holiday

未读,
2015年5月11日 10:15:302015/5/11
收件人 json-...@googlegroups.com
Two thoughts come to mind on that: 

1. Since properties of a JSON object are unordered by definition, there seems to be no gain from specifying an order in a schema. If you've got an implementation where property ordering DOES matter, at that point you're not really using JSON anymore . . . you're using a home-grown format very, very similar to JSON.

2. When choosing between an array/object, my first thought is always "How will people access this data?" If the natural way to use it is iteration and ordering matters, then an array is the obvious choice. If random access is required or useful, an array really makes that a PITA. It requires iterating over the whole thing and then reading it into a more suitable data type on the client side. With JSON Schema, iteration over the properties object is often useful, but for validation random access is far better. If you went with an array, you'd need more than 'id', also, you'd need something like 'keyword'.





--
You received this message because you are subscribed to the Google Groups "JSON Schema" group.
To unsubscribe from this group and stop receiving emails from it, send an email to json-schema...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Simon Heimler

未读,
2015年5月11日 10:43:572015/5/11
收件人 json-...@googlegroups.com
Hello Pete,

yes, that makes sense. Since objects do not have a natural order, JSON Schema does not need to define one.

It's really some edge cases (like MDE) where this makes sense.

Best,
Simon

Pete Holiday

未读,
2015年5月11日 11:12:502015/5/11
收件人 json-...@googlegroups.com
Can you play that out a bit more? I'm not clear on how ordered keys would impact MDE.

Simon Heimler

未读,
2015年5月12日 01:27:302015/5/12
收件人 json-...@googlegroups.com
Yes:

Let's say, you want to generate forms from your JSON Schema. That's a pretty good use case, because the JSON Schema already contains a lot of information to do that. You'd want to add some additonal properties that are form-generation-related, of course.

It is crucial (for UX) that the form inputs will be rendered in the order you've specified and that the form remains in that order (and is not randomly shuffled). 

Once you've submitted the form the resulting data may be unsorted again, it dosen't matter. If the order is of matter after submitting the data, an array would definately be the only right data format and using an object a mistake in choice of data structures. In that case the use of "properties" would be wrong in the first place, "items" needs to be used instead. 

For Validation of the resulting Data, the property order doesn't matter as you see. As you pointed out, an object structure is much nicer to work with in this case. But for the creating of the form, the property order it is still mandatory.

So using the propertyOrder for validating the order of properties is probably not a good idea, since the data structure itself does not guarantuee that order. It simply is the wrong choice, though in many cases that choice has been made because current JavaScript VM's are "nice" and preserving the order up to a certain size of the object. (But they would not have to, and once you exceed that size your whole program would fall apart if it depends on that order) 

This makes the case a bit tricky. If you think it in data structures, the properties attribute is a Collection (that will be serialized to an array)

I hope that'll make it a bit more clear?

Best,
Simon

--
You received this message because you are subscribed to a topic in the Google Groups "JSON Schema" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/json-schema/GOJ1IochoVE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to json-schema...@googlegroups.com.

Simon Heimler

未读,
2015年5月12日 01:52:552015/5/12
收件人 json-...@googlegroups.com
Now that I've thought about it:

It would probably most consequent to have a "generation-schema" that contains all those additional information that are needed to generate systems (including property order). The actual data-schema could then be generated from the generation-schema and will be a reduced version.

Since the generation-schema (and the resulting system) already knows about the property order, the data-schema doesn't need to know about it. If data is imported again, the system can import it in that already existing order.

But I'm really just in the process of wrapping my head around this subject. Not sure what the most elegant approach would be.

Simon
To unsubscribe from this group and stop receiving emails from it, send an email to json-schema+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to a topic in the Google Groups "JSON Schema" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/json-schema/GOJ1IochoVE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to json-schema+unsubscribe@googlegroups.com.

Pete Holiday

未读,
2015年5月12日 19:52:332015/5/12
收件人 json-...@googlegroups.com
That totally makes sense. I agree with you that including UX data for the form is probably not a good thing to have in the JSON Schema spec, but in practice I'd probably extend JSON Schema with my own fields to make that work.

I'd probably *not* call the fields 'propertyOrder' because that, to me, suggests something different from even the name 'formFieldOrder'. But what I might do instead is give every object a 'formFields' keyword that contains an array of field names. That would give you a relatively small extension to JSON Schema that would have all of the benefits of the ordering of an array along with the benefits of keyword lookup.

-Pete

--
You received this message because you are subscribed to a topic in the Google Groups "JSON Schema" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/json-schema/GOJ1IochoVE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to json-schema...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.
回复全部
回复作者
转发
0 个新帖子