Alternatively, text documents commonly have embedded tables, so textual and tabular data can be displayed on the same page. What if tables were implemented with row and column labels, and support for formulae?
In ALL things, strive for ><>, Chris On Sat, Feb 13, 2010 at 2:51 AM, James Rhodes <[email protected] > wrote: > It occurs to me that Wave essentially only supports document-based > information, that is all waves and wavelets are designed to hold > Google Docs Document-type information. This is fine for majority of > the information that will be shared through the Wave protocol; email, > instant messaging and basic collaboration are all formatted as such. > > However, there are some types of collaborative documents which can't > be, at the moment, stored effectively using the Wave protocols - take > Spreadsheets for example. In the case of Spreadsheets, you not only > want people to be able to collaboratively set and change the cells in > the document, but you could also allow people to attach wavelets onto > the Spreadsheet cells. > > One might suggest the use of Wave embeds for anything other that > document-based information, however this is a very large barrier to > usability. Imagine a Wave document where the only thing inside it was > a Wave embed, one that renders and handles spreadsheets on another > server. Not only does this provide a barrier to usability on the Wave > client (the document-editing toolbars are unnecessary and only invite > users to create wavelets outside of the intended document), but > essentially reduces Wave to being a container for other collaborative > platforms, where the power of Wave is not taken advantage of. > > I was unable to find an example of what a Wavelet actually looks like > in XML form, but I suggest the following additional parameters to > Wavelets. I'll explain each of the following parameters below. > > * documentType="application/spreadsheet" > * documentSpecification="<url to document type specification>" > * documentFallbackGadgetURL="<url to gadget>" > * documentFallbackErrorURL="<url to a webpage>" > > documentType informs the Wave client of the type of content the Wave > contains, whether this be text/html for standard Wave documents, > application/spreadsheet for Spreadsheets or application/slides for a > Slideshow. The format of the parameter should match that of the > internet content types, but it does not necessarily have to use the > currently defined MIME types used on the internet (as I can see that > some would have no use, such as application/msword). documentTypes > should be kept unique, preferably having a set of predefined types > established as part of the Wave protocol. However, in case of clashes > or unknown document types, the documentSpecification parameter plays > an important role. > > documentSpecification should never be present to the end user, but is > instead used to distinguish areas where documentTypes may clash > (obviously without the original author of the documentType's > intention). More importantly, it allows developers of Wave clients to > track the rise of unknown documentTypes and set about implementing > support for them into their Wave client as per the specification that > was linked to. However, as we want to enable the user to take part > collaboratively regardless of whether their Wave client supports it > natively, the documentFallbackGadgetURL can be used to specify an > embed for the Wave client to use in place of it's own native handling. > > documentFallbackGadgetURL is not a required parameter for the Wavelet > to provide, however the Wavelet must provide either > documentFallbackGadgetURL or documentFallbackErrorURL. The > documentFallbackGadgetURL points to an gadget which essentially > replicates the functionality that a Wave client would implement itself > natively. If a Wave client can not display a gadget, it should > fallback to documentFallbackErrorURL. > > documentFallbackErrorURL defines a URL which the Wave client will > display along with the appropriate error message. The URL should > specify a webpage that instructs the user how they can further > participate in the Wave. > > The following images show how Google Wave might represent a situation > where it is unable to render a gadget, and a situation where it is > natively rendering a spreadsheet (to highlight the difference between > native rendering and how it would currently be displayed in an > gadget). Both are direct links. > > http://www.roket-games.com/weblink/579/no_support.png > http://www.roket-games.com/weblink/580/spreadsheet.png > > So those are my thoughts and ideas on the matter, feedback and > suggestions are very much appreciated (obviously the Wave guys would > have the final say if they decided to implement this). I'll create a > Wave in the [email protected] to get further feedback there > as well. > > Regards, James. > > -- > You received this message because you are subscribed to the Google Groups > "Google Wave API" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<google-wave-api%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/google-wave-api?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Google Wave API" 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/google-wave-api?hl=en.
