How would upgrading the schema of an existing document work with signed deltas? Would the server construct a new delta for the schema upgrade, and sign it as itself?
On Thu, Feb 4, 2010 at 11:30, Daniel Paull <[email protected]> wrote: > 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. > > -- Anthony Baxter, [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.
