Hi Tad, I definitely see a demand for supporting new document types. However, enforcing them upon each submit-request can cause significant computation overhead on the server. The other options I could imagine:
a) Keep it as it is: The server cares for well-formedness an the client has to deal with the documents one way or the other b) Option a) plus lazy evaluation. Every client can indicate the server that a document is broken and the server checks & rolls back. Your proposals are technically cleaner, but I am really worried about performance ... Cheers Torben 2010/2/2 Tad Glines <[email protected]> > Interoperability requires that clients and servers agree on the wave > content structure (schema). There is work in process for the conversation > model, but there is no general mdoel for how a client or server can describe > the allowed schema of a wave it creates. In XML this is already solved. And, > while wave documents are not XML, they allow a similar structure. It would > seem to me that a very useful addition to wave would be the ability specify > and determine the schema associated with a wave/wavelet/document. > > There is already some model code that supports this (DocumentSchema and > BootstrapDocument), but there is no way for a server to know which schema, > if any, should be enforced. There seems to be two possible ways to handle > this. One is to associate a schema with a particular namespace prefix. So, > for example, documents with names starting with "b+" would have to conform > to the blip schema and documents with the name "conversation" would be > required to conform the conversation schema and blips references therein > would have to conform to the blip schema. An alternative would be to add > some means to specify a schema for a wave/wavelet/document upon creation or > later during modification. In the later case, there would need to be a > mechanism for specifying the schema to use, either by well known name, of by > including the actual specification. > > The schema to namespace mapping seems the easiest to implement but the > other method provides more possible flexibility at the expense of additional > complexity and possible conflict resolution issues. > > Has Google, or anyone else considered this matter? > > -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. > -- --------------------------- Prof. Torben Weis Universitaet Duisburg-Essen [email protected] -- 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.
