Hi Tad, Thanks for raising this matter. We have indeed considered this problem and many of the options that have arisen in this thread.
The wavesandbox wave server already enforces schemas. We plan to continue with this approach. The current schemas are hard-coded, not very flexible, and based on the document namespace (e.g. b+ -> blip schema). We're working on a better approach. Our current plan is for schemas to be stored in wavelets, written in a schema language, and referenced by the documents to which they apply. The reference would include a version and signature of the schema wavelet. We're still thinking about ways to upgrade the schema of a document. Suggestions welcome! The problems pointed out above are tricky indeed. Enforcing schemas at the server is not prohibitively expensive, and well worth it for the guarantees that can be provided about the data. Cheers, Alex On 17 February 2010 15:49, Tad Glines <[email protected]> wrote: > There seems to be three possible ways to enforce a schema in wave: > 1. Play nice: Clients are expected to play nice together. > 2. Server enforced: The server (specifically the federation host) > enforces the schema. > 3. Agent enforced: Extend the existing agent interface so that the > server can pass an transformed but unapplied delta to a "schema" agent > for verification. > > The play nice has fundamental problems with trust and consistency. All > it takes is one rogue client (accidental or intentional) and many a > wave go "shiny". > > The server enforced model can work, but there's a question of how the > server would know what schema to enforce on which documents (or set of > documents). For some common schemas a fixed namespace to schema > mapping might work. But for less well know clients, this could become > problematic. Defining a schema in a wave might work, but only if there > was a way to assign that "schema" wave to the "content" wave and > ensure that the "schema" wave was propagated along with the "content" > wave. The existing wave mechanisms don't support this. > > The agent approach has the potential to make things a little simpler. > We already have the concept of agents that perform actions within a > wave (spelly for example). And some robots being developed are > performing content control type actions. And users are becoming > familiar with the idea of adding a robot/agent to their wave to > enhance it. So perhaps we can extend this "plug-able capability" > concept to include the addition of content enforcement capabilities to > agents. So, for example, when I create a "conversation" wave the > "conversation" agent is added as a non-removable participant to the > wave and acts as the schema enforcement agent. All deltas would be > passed to the agent prior to being applied. The agent would have the > option of requesting additional content from the wave before > approving/disproving the delta. This might also work with robots, but > has the potential to cause a serious bottleneck if the robot isn't > implemented/provisioned appropriately. > > -Tad > > -- > You received this message because you are subscribed to the Google Groups > "Wave Protocol" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<wave-protocol%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/wave-protocol?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en.
