Simple solution, yes. But it sure sucks to be stuck on an old schema if the new schema was developed to support new features that you want to use... Perhaps a not-so-simple solution should be thought through.
> just as you don't change the schema of an XML document once it has been > created eh? I've seen OpenOffice upgrade my documents form an old schema to a new one and they're XML docs, right? I expect Microsoft does the same thing with their fancy new XML formats too. Dan On Feb 4, 3:38 am, Tad Glines <[email protected]> wrote: > The simplest solution is to not allow changing the schema once the > wave is created, just as you don't change the schema of an XML > document once it has been created. > > -Tad > > > > On Tue, Feb 2, 2010 at 11:32 PM, Daniel Paull <[email protected]> wrote: > > If we start talking about versions of shemas, then we are going to > > have to talk about clients that persist waves and allow offline work. > > Imagine that schema 1 is used to create a wave and a user takes the > > wave offline to do some work. The server is then upgraded to schema > > version 2. The user then reconnects to the server, expecting to > > commit their offline work. How do you merge in operations performed > > against the old schema version? It would be really bad form to not > > accept the changes as the changes may represent a lot of work. > > > Cheers, > > > Dan > > > On Feb 3, 6:36 am, Tad Glines <[email protected]> wrote: > >> Some level of schema/structural checking will be required in order to > >> prevent malicious users from corrupting waves (or crashing the server). If > >> the server does nothing with the content other than ensure that the > >> operations are legal (WRT basic wave OT), then no schema checking would be > >> required at the server level. But if the server has to do something with > >> the > >> content (e.g. content transormation) then some level of structural > >> constraint would need to be enforced by the server. We've already seen > >> cases > >> where improper ordering of operations crashes a wave on wavesandbox. So > >> some > >> level of structural constrain is needed. > > >> In the case where there are multiple client implementations and multiple > >> conversation model versions (it'll happen) there will need to be some means > >> of communicating to clients and server what model is in use for a wave. It > >> could be as simple as a "model_version" attribute in the root > >> "conversation" > >> element. Or it could be as complex as a special wavelet in the wave that > >> defines the schema to namespace mapping in force for that wave and it's > >> wavelets. Something other than "everybody play nice together" will be > >> needed. > > >> -Tad > > >> On Tue, Feb 2, 2010 at 1:45 PM, Torben Weis <[email protected]> wrote: > >> > 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%2bunsubscr...@goog > >> >> legroups.com> > >> >> . > >> >> 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]<wave-protocol%2bunsubscr...@goog > >> > legroups.com> > >> > . > >> > 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 > > athttp://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.
