Schemas are good because you kind of know what to expect with a schema. They’re also what you probably meet 99% of the time. Schemalessness is great because it allows you to slough off the problematic schema-being-too-rigid thing. Of course, it’s difficult to use schemaless stuff because you don’t know what to expect.
And at this point you create a schema. Maybe you didn’t intend to create a schema, but unknowingly or not, you created one. Now you have a schema and the good times can begin; you can get back to solving the big issues of programming, like roundtripping to HTML forms and whatnot. We especially like predictable when we think about getting our data into HTML.
But then you encounter the problem that caused you to choose a schemaless data model, which you cunningly solve by making the schema larger. Larger schema, more bandwidth; cover more edge cases. Great. I wrote about FrameFrame a while ago.
Right, so the schemaless thing is good. So, we go with that. Then we create a layer on top that allows us to interact with the data model — schemaless as it is — using HTML forms in an abstract way. Thus, the data model is not directly implemented in the interface. Schemaless. Except every record is derived from the same schema because the input is always the same.
I’m not sure how to create an input framework for schemaless data models that don’t coerce their own schema. I think such workflows can be created, but they’re probably rather tedious to use for brains so used to schema-driven interfaces. So maybe we shouldn’t. I concluded this very thing at SWIB11, just before they started knocking on the tables.
And I keep managing to forget it. Until I don’t.