Skip to topic | Skip to bottom
Home

Tesi
Tesi.NuovoCSIr1.2 - 25 Aug 2006 - 16:30 - ChiaraPilotopic end

Start of topic | Skip to actions

Collaborative Services Initiative - a Proposal

Fabio Vitali, University of Bologna

Describing collaboration

In the following, we will refer to a collaboration as one or more conversations between peers. Each conversation is composed of several utterances, each of which comes from a single party. A session is a time-bounded fragment of a conversation with a beginning and an end, and whose result is fit to become a full-fledged resource ready to be stored and given a real URL.

One of the assumptions made for this proposal is that there exist a finite number of characteristics that completely define and describe the conversation and the type of collaboration that the conversation makes possible.

In particular, we believe that all types of conversation can be fully described by positioning it along five different axes:

  1. the relation with the resource
  2. the turn-taking mechanism
  3. the data format of each utterance
  4. the visibility
  5. the update protocol for each utterance

Ogni dimensione, secondo le capacita' di ogni tecnologia potra' assumere un valore a scelta tra quelli disponibili e la sequenza di tutti i valori delle dimensioni identifichera' univocamente un determinato tipo di conversazione.

The relation with the resource

A first dimension to classify and evaluate collaborative applications regards the relationship between the collaborators and the resources being collaborated on:

  1. collaboration ABOUT a resource,
  2. collaboration ON a resource,
  3. collaboration BEING the resource.

This distinction allows us to describe a number of different situations were the resource being worked on influences the style of the collaboration.

In collaborating about a resource, a main resource exists and is not changed, while the collaboration happens with utterances making references to this or that bit of the resource. For instance, external links and external comments (a la Annotea) allow collaborators to express secondary information on a main resource without modifications. A secondary server would collect secondary data and be able to provide them on request to collaborating partners. Being secondary information there is no risk of polluting the original resource and no problems in maintaining consistency and ensuring access control.

When collaborating on a resource, a main resource exists and is changed by the act of collaborating. Each utterance constitutes a modification to the original resource. For instance, shared editing applications, xanalogical editors, and MUD clients, all express utterances as editing commands on a shared resource. At the end of the editing session, the resource gains a new (different) state and is saved accordingly on the server. Applications need to preserve the sequence of utterances in order to maintain consistency, and may provide whole-resource or fine-grained locking mechanisms and access control functionalities in order to ensure a smooth management of the evolution of the content of the resource.

When collaboration is the resource, there is no main resource to which associating the utterances. The utterances in fact are the resource being worked on. Chats, fora, shared whiteboards, gaming applications, etc., all share the idea of the conversation and the result of the collaboration being the very same thing. Each session can be saved, if so desired, and transformed into a full-fledged resource, but this is not necessary. Some applications may need to ensure a rigorous turn-taking, others may allow a more flexible approach.

The turn-taking mechanism

Traditionally, collaborative systems are described as placed onto a two-dimensional time/space matrix:

  • Local vs. remote applications,
  • Synchronous vs. asynchronous applications.

Thus for instance shared editing could be either synchronous or asynchronous depending on the kind of collaboration patterns being expressed, while a chat system would necessarily be synchronous.

The distinction between local and remote applications, at least in the Web domain, does not affect the conversation protocol, although it may affect the type of data being exchanged and the type of application being implemented. On the other hand, the distinction between synchronous and asynchronous application has a big importance in the technical architecture needed to implement each type of application.

We propose here a different approach to the synchronous vs. asynchronous concept: we consider as relevant the rules for turn-taking in the collaboration itself: the set of rules for gaining (or being refused) the right to produce an utterance at any given moment of the conversation.

Turn-taking can be characterized by two parameters:

  1. Exclusiveness: are one, some, or all participating parties allowed at some moment to produce and share an utterance (in WebDAV? terms they are known as exclusive lock, shared lock, no lock)? In case of a shared lock, can it be made an exclusive lock only locally (for instance, around the part of document I am working on)? Possible values: noLock, localLock, globalLock.

  1. Numerosity: In case of a lock, is the party with the turn allowed to produce at most one utterance for each turn, or can it produce several? One utterance per turn means that the lock is released automatically at the end of the utterance, otherwise the turn owner will have to explicitly release the lock when he/she's finished. Possible values: singleUtterance, multipleUtterance

Some examples may help in clarifying this schema:

  • A synchronous distributed card application will grant each player a globale and single lock for playing one turn of card. No other player may play a card, but as soon as the card is played by the player owning the turn, the lock is automatically released and granted to the next player.
  • A synchronous chat application with restricted attendance will grant each legal participant a turn in a non exclusive manner (localLock). The are no constraints except for the need to identify the restricted set of legal participants and to provide a correct sequencing of the utterances.
  • A synchronous shared editing application will grant a restricted number of participant a local, multiple lock. While a person is modifying a part of the document, he/she can provide multiple utterances on it, but no-one else is allowed to modify around the document fragment he/she is working on.
  • An asynchronous shared editing application will grant one user at a time a global, multiple lock on the resource. While the user owns the lock, no-one else is allowed to modify the document. As soon as he/she is finished, he/she will voluntarily release the lock and let someone else claim it.

The data format of each utterance

Of course the type of collaboration application will be determined by the exact nature of the data being exchanged. Thus, a chat or a forum will allow only textual utterances (or maybe HTML), while a shared drawing board will require individual drawing operations (maybe SVG elements), a text editor will require text editing commands (XML fragments, possibly), and a game application will require legal moves. In ogni caso nuovi formati potranno essere specificati attraverso il tipo MIME application/x-.

The visibility

Some technologies allow users to know who the receiver of the message will be before it is delivered. For example, when a user sends an email he has the ability to control who will receive it. However, in other technologies, there is no way to find out who can possibly obtain the message, such as in chat rooms or in multiplayer role-games. For this reason we use two values, private and public, which respectively indicate collaborations in which the sender knows the receivers of the message and collaborations in which this is not possible.

The update protocol for each utterance

The type of information update that is available between parties in the collaboration is of great importance in determining the type and the success of a collaborative application. Synchronous applications typically employ a self-defined transfer protocol, which is usually connectionfull, bidirectional, possibly broadcast.

On the other hand, the web is based on the HTTP protocol, which is client-initiated, connectionless, client-server. In order to obtain synchronous behaviour, something has to give. We could characterize the connection type of the transfer protocols as follows:

  1. pull: user-prompted, client-initiated requests to a shared server. A plain pull connection is not the best choice for collaboration, for it requires the user to manually ask each time for the updates coming from other users. As such HTTP appears somewhat limited when used as a purely pull protocol.
  2. pseudoPush (or polling): automatic (time-prompted), client-initiated requests to a shared server. HTTP can be used for pseudoPush, and in fact it has often used this way: the client relies a settable time-out, after which it contacts the server and ask for new data.
  3. realPush: utterance-prompted, server-initiated commands to the client from a shared server. Real push protocols may require a connection to be maintained indefinitely between client and server: the client listens on the connection for new events happened somewhere else, and sometimes, as needed, sends up new events originating on its side. HTTP is not designed for this kind of connections, and cannot be used for real push connections. On the other hand, it could be slightly twisted and modified to this purpose.

This proposal of protocols is independent of any choice in the type of the connection, but of course the features and working patterns of the actual applications will heavily depend on it. In particular, relying on plain HTTP could seriously limit scalability of the proposed protocols.

The proposal

We propose to create a new W3C working group, tentatively called "Collaborative Services Initiative" (or CSI), whose purpose is to produce and disseminate a number of protocols and best practices that are meant to standardize and integrate the vast majority of collaborative applications currently available on the web.

To this end, we foresee the need for two fundamental protocol, the "collaboration agreement protocol" or CAP, that allows participating parties and servers to agree on the type of collaboration according to the aforementioned parameters, and the "collaborative utterance markup language" (CUML), that allow individual parties to contribute utterances according to the agreement that are successfully distributed to all other parties, possibly through the central server. We use XML and SOAP to express both CAP and CUML. Inoltre le parti che vogliono iniziare una collaborazione potrebbero avere bisogno di meccanismi di sicurezza sia per quanto riguarda la protezione dei messaggi sia per quanto riguarda l'identificazione dei partecipanti. A questo proposito i messaggi potrebbero dover essere criptati e firmati e i partecipanti potrebbero dover esibire dei certificati per attestare la propria identita'. Due meccanismi ci vengono in aiuto per queste esigenze: da una parte XML Signature permette di applicare una firma digitale per garantire confidenzialita' e integrita' a documenti XML; dall'altra XML Digital Encryption che permette di codificare sia interi documenti sia singoli elementi XML.

As detailed in a later section, the utterances may want or be required to use a number of well-known and no-so-well-known W3C standards and quite-standards, giving new life and opportunities to the half-forgotten ones. For this reason, it could be appropriate to produce a number of guidelines, or best practices, on how to use said protocols and languages to the best use within the collaboration service protocols. So a third class of products of this WG would be a series (whose number and content are yet to be determined) on collaboration best practices documents (BPC) for the exploitation of other W3C languages within the CSI framework.

Finally, as mentioned, HTTP can only be used in a limited number of collaboration activities, due to its intrinsically connectionless and client-initiated nature. If the conclusion was reached that HTTP is not adequate not even considering pseudoPush connections, then a new transfer protocol (or a modification of HTTP) would be appropriate. Such transfer protocol (tentatively called Synchronous Data Transfer Protocol or SDTP), would then be used with or instead of other existing transfer protocols, including HTTP, SMTP, NNTP and others for the establishment of collaborative connections.

The collaboration agreement protocol (CAP)

The CAP allows interested parties to decide on a collaboration framework whose collaboration rules are explicitly agreed upon. Each prospective client, upon requesting to join in a conversation, would propose its capabilities and preferred collaboration characteristics. The server would respond with the closest matching set of characteristics that are being used in the ongoing conversation. The client would then be free to accept them or disconnect altogether. For instance, clients and servers could discuss about:

  • the number of conversations employed in this collaboration. For each conversation:
    • the relation with the base resource
    • the URI of the resource
    • the turn-taking exclusiveness and numerosity
    • the data type being exchanged in each utterance
    • the update protocol for each utterance
    • the granularity of the utterance
    • the re-negotiability of the agreement during the collaboration
    • the transfer protocol to be used during the collaboration
    • etc. ...

The number of conversations being carried on during a single collaboration instance does not have to be one. For instance, a sophisticated synchronous text-editing application could maintain a conversation on the actual editing commands on the text, plus an additional short-term chat-like conversation between the distributed authors, plus a comment base for long-term written comments on specific parts of the text. Each conversation is independent of the other, and has largely different characteristics.

The re-negotiability of the agreement will be discussed at the end of this document.

We expect to use RDF for the expression of rules and characteristics, and to define a rigorous ontology for easy matching and discussion. The protocol would also provide a number of error situations that could be notified to a wrongdoer: providing utterances out of turn, trying to modify the base resource when the collaboration does not allow it, providing unknown types of utterances, and so on.

The collaborative utterance markup language (CUML)

Each individual contribution to a conversation is called a utterance. Each utterance must provide context information whenever is received by the collaboration server:

  • what conversation it belongs to,
  • who provides it, and which certificates are being used
  • the resource (if any) being referred to
  • where exactly in the resource
  • the data being provided.

The collaborative utterance markup language provides a way for clients to express this kind of information. Thus CUML captures the nature of each utterance (i.e., atomic and individual contribution to the conversation in a collaborative session), the data type (ranging from plain text, as in a sentence in a chat, to complex structured data objects such as SVG objects being added to a shared drawing environment, etc.

CUML does not limit the granularity of the data being exchanged, which can range from single characters for synchronous editing applications to whole sentences in a chat or forum. This parameter is decided in the CAP protocol.

We use XML for the expression of utterances, but we also expect to define a rigorous ontology for easy identification and interpretation of each utterance.

Fasi della collaborazione

Quando due o piu' applicazioni vogliono iniziare una collaborazione, prima di scambiarsi i messaggi che la costituiscono, devono fornire le proprie capacita' collaborative in modo che si possa verificare che le parti abbiano caratteristiche tali da permettere la creazione di una nuova conversazione. L'interazione dunque avviene in due fasi: nella prima ogni parte redige il proprio profilo di collaborazione in cui specifica le caratteristiche dell'applicazione e le preferenze dell'utente attraverso il protocollo CAP; nella seconda fase le parti inviano le espressioni con contenuto attraverso il protocollo CUML, e in accordo con i profili precedentemente redatti.

Dopo aver creato il proprio profilo ogni parte lo invia al server collaborativo che risponde con il risultato del confronto. Il destinatario di una richiesta puo' accettare la proposta o rifiutarla sia perche' non ha caratteristiche comuni sia, nel caso di conversazioni tra piu' partecipanti, perche' non vuole comunicare con gli altri invitati. Una volta che le parti si sono accordate si passa alla seconda fase, quella dello scambio di messaggi con contenuto.

Per capire meglio come venga creato il profilo di collaborazione di ogni partecipante analizziamo un esempio. Consideriamo un utente che possiede un programma di chat che permette lo scambio di messaggi testuali e l’invio di file. Il nostro utente vuole comunicare con una sua amica ma non sa quali conversazioni ella possa effettuare. A questo proposito crea il suo profilo e lo invia al server che si occuperà di aspettare il profilo dell’altro partecipante, confrontarlo con quello del nostro primo utente ed inviare ad entrambi la risposta. Nella creazione del profilo si analizzano innanzitutto le conversazioni messe a disposizione dal software in uso. Nell’esempio la chat metterà a disposizione:

  • messaggi privati con ricezione automatica
  • allegati privati con ricezione automatica

Successivamente l’utente può specificare la preferenza di una conversazione o più rispetto alle altre presenti nel profilo attraverso l’attributo favourite o può scegliere il modo in cui essere aggiornato attraverso l’attributo update. Nel caso della chat generalmente il modello d’aggiornamento è realPush poiché le espressioni generate dall’altra parte vengono trasmesse non appena inviate ma l’utente può decidere di volerle ricevere ogni tot di tempo fissato o magari di richiederle manualmente. Inoltre l’utente potrebbe voler assicurare il destinatario sulla propria identità e a questo scopo inserire nel campo sender oltre al suo nome anche il suo certificato. Inoltre potrebbe voler garantire l’integrità e la confidenzialità dei dati che invia e perciò criptare e firmare ogni messaggio. Un esempio di profilo risultante potrebbe essere il seguente:

<cap:proposal xmlns:cap="http://www.cs.unibo.it/CAP/1.0/" renegotiable="true"> 
    <cap:sender uniqueName="Davide1978">  
       <cap:name>Davide Rossi</cap:name> 
    </cap:sender> 
    <cap:request type="createNew"/> 
    <cap:conversation  
     id="a01"  
     favourite="true"  
     media="text/plain" 
     quality="1.0"> 
       <cap:isResource> 
          <cap:noLock> 
             <cap:multipleUtterance update="realPush" visibility="private"/> 
          </cap:noLock> 
       </cap:onResource> 
       <cap:transport> 
          <cap:transportProtocol version="1.1">HTTP</cap:transportProtocol> 
          <cap:securityProtocol version="3.0">SSL</cap:securityProtocol> 
       </cap:transport> 
    </cap:conversation>    
    <cap:conversation  
     id="a02"  
     favourite="true"  
     media=" application/octet-stream" 
     quality="1.0"> 
       <cap:isResource> 
          <cap:noLock> 
             <cap:multipleUtterance update="realPush" visibility="private"/> 
          </cap:noLock> 
       </cap:isResource> 
       <cap:transport> 
           <cap:transportProtocol version="1.1">HTTP</cap:transportProtocol> 
            <cap:securityProtocol version="3.0">SSL</cap:securityProtocol> 
       </cap:transport> 
    </cap:conversation>   
</cap:proposal>    
Ogni proposta di collaborazione può essere di due tipi. O il mittente vuole invitare un altro partecipante a creare una o più conversazioni oppure è già in corso una collaborazione e il mittente vuole invitare qualcun altro a partecipare. In questo caso il mittente vuole creare una nuova conversazione perciò il campo Request assume valore createNew. Poiché la tecnologia permette due tipi di conversazione saranno presenti nel profilo due elementi conversation. Il primo elemento specifica l’invio di messaggi testuali. Questo si riconosce dal fatto che il valore dell’attributo media è text/plain. Le conversazioni che la chat può creare sono isResource infatti questi elementi sono presenti all’interno degli elementi conversation. Inoltre non vi sono meccanismi di turno, infatti le conversazioni sono noLock. L’utente vuole ricevere i messaggi non appena disponibili perciò il valore del campo update è realPush. Inoltre si utilizza il protocollo HTTP per trasportare i messaggi e il protocollo SSL per garantire la confidenzialità. A questo punto, dopo aver creato il proprio profilo, l’utente lo invia al server.

Confronto tra profili

Non appena il server riceve un profilo aspetta che il partecipante invitato invii il proprio, per poter così, procedere al confronto. Consideriamo come secondo partecipante un utente che possiede un programma di editing condiviso che permette oltre alla conversazione di modifiche sul testo anche una conversazione chat-like per lo scambio di messaggi testuali. Maria Bianchi ha ricevuto una richiesta di comunicazione da Davide Rossi che aveva a disposizione un programma di chat per l’invio di messaggi e di oggetti. Per poter rispondere alla richiesta Maria deve creare il suo profilo e inviarlo al server che si occuperà di confrontare i due profili. Nella creazione del profilo anche in questo caso si analizzano innanzitutto le conversazioni messe a disposizione dal software in uso. Il programma di editing metterà a disposizione le seguenti conversazioni:

  • modifiche testuali locali private su una risorsa con ricezione automatica
  • messaggi privati con ricezione automatica

Anche Maria, a questo punto, specifica le sue preferenze per ogni conversazione che è capace di fare, indicando quali preferisce intraprendere e in che modo desidera essere aggiornata. Un esempio di profilo risultante potrebbe essere il seguente:

<cap:proposal xmlns:cap="http://www.cs.unibo.it/CAP/1.0/" reegotiable="true"> 
    <cap:sender uniqueName="Stellina">  
       <cap:name>Maria Bianchi</cap:name> 
    </cap:sender>       
    <cap:request type="createNew"/> 
    <cap:conversation  
     id="b01"  
     favourite="true"  
     media=" application/x-text-editor" 
     quality="1.0"> 
       <cap:onResource uri="http://www.sito.com/risorsa1"> 
          <cap:localLock grain="page" token="pool"> 
             <cap:multipleUtterance update="realPush" visibility="private"/> 
          </cap:localLock> 
       </cap:onResource> 
       <cap:transport> 
           <cap:transportProtocol version="1.1">HTTP</cap:transportProtocol> 
            <cap:securityProtocol version="3.0">SSL</cap:securityProtocol> 
       </cap:transport> 
    </cap:conversation>   
    <cap:conversation  
     id="b02"  
     favourite="true"  
     media="text/plain" 
     quality="1.0"> 
       <cap:isResource> 
          <cap:noLock> 
             <cap:multipleUtterance update="realPush" visibility="private"/> 
          </cap:noLock> 
       </cap:onResource> 
       <cap:transport> 
          <cap:transportProtocol version="1.1">HTTP</cap:transportProtocol> 
          <cap:securityProtocol version="3.0">SSL</cap:securityProtocol> 
       </cap:transport> 
    </cap:conversation>     
</cap:proposal>    

Anche in questo caso sono presenti nel profilo due elementi conversation poiché la tecnologia permette due tipi di conversazione: quella di modifiche e quella come la chat. Quest’ultima ha gli stessi valori della conversazione testuale nel profilo del primo utente. La conversazione di modifiche sul testo, invece, è caratterizzata dai seguenti valori: la collaborazione è onResource e la risorsa su cui si vuole collaborare è identificata attraverso l’attributo uri. Per quanto riguarda i meccanismi di turno, le conversazioni sono localLock poiché si vuole che solo un utente alla volta possa modificare una determinata sezione ma si vuole anche lasciare i partecipanti liberi di effettuare modifiche contemporanee su parti diverse. La dimensione delle sezioni in cui dividere il testo è stabilito nel campo grain e come si può osservare il valore è page. Questo significa che collaboratori potranno effettuare modifiche simultaneamente ma solo a patto di farlo in pagine differenti. Ogni pagina sotto modifica verrà considerata come bloccata da un lock e tornerà disponibile non appena il partecipante con il turno lo rilascerà. Il meccanismo dei token lascia che ogni utente decida quando modificare una parte libera; infatti, il valore di questo campo è pool. L’utente vuole ricevere i messaggi non appena disponibili perciò il valore del campo update è, anche in questo caso, realPush e si utilizzano i protocolli HTTP e SSL.

Non appena il secondo partecipante invia il suo profilo al server, si procede al confronto. In generale i profili potrebbero essere analizzati elemento per elemento partendo dall’inizio oppure si potrebbero seguire delle regole di precedenza. Una possibilità è quella di selezionare inizialmente solo le conversazioni preferite da ciascun utente. Queste ultime si differenziano da quelle che ogni partecipante è semplicemente capace di fare attraverso il valore true attribuito al campo favourite. Nel caso non ci fosse corrispondenza tra le conversazioni preferite si potrebbe passare all’analisi delle restanti conversazioni disponibili. A prescindere da come viene effettuata l’analisi dei profili e da come le parti ricevono le informazioni necessarie per poter iniziare la collaborazione, quello che si vuole mostrare è cosa si ottiene dal confronto. Per questo scopo riprendiamo lo scenario descritto nei paragrafi precedenti in cui un utente aveva a disposizione una chat capace di inviare messaggi e allegati mentre l’altro utente aveva a disposizione un editor collaborativo con possibilità di fare modifiche sul documento condiviso e di inviare messaggi testuali chat-like. L’unica conversazione che le parti hanno in comune è:

  • messaggi privati con ricezione automatica

Questa conversazione sarà, dunque, quella che potrà essere intrapresa tre i due partecipanti.

L'Agreement

L’analisi dei profili potrebbe concludersi con la generazione di un documento di accordo; altrimenti, l’analisi potrebbe concludersi con l’invio da parte del server di un responso alle parti senza la generazione di alcun documento di accordo. Nel caso venga generato un documento, questo potrebbe risiedere sul server nel lasso di tempo necessario ad inviare alle parti il responso e poi cancellato subito dopo o potrebbe essere salvato come un documento vero e proprio ed essere inviato alle parti. Ogni partecipante, a questo punto, dovrebbe analizzare il documento ricevuto per poter capire quali conversazioni potranno essere effettivamente utilizzate nella collaborazione.

Collaboration best practice documents (CBP)

As mentioned in the next section, collaboration could make good use of a number of existing W3C protocols and languages, providing new applications and reasons to exist to a number of them.

Of course, it would be necessary to identify exactly how these languages and protocols are to be used within the CSI framework, for which reason some "Best Practices" have to be described. These would be providing hints and suggestions on how to use existing W3C/IETF standards and almost-standards within the collaborative applications. These standards include WebDAV?, XLink, XPointer, XML Include, and XML Fragment, etc.

Synchronous Data Transfer Protocol (SDTP)

Synchronous collaborative applications may find a hard time in using the plain and standard HTTP protocol for the delivery of individual contributions. As stated previosuly, HTTP allows both pull and pseudoPush connection styles, but in no way a real push connection. Pseudo-push may solve many of the connection problems implied by a full synchronous collaboration application, but at the expense of network traffic.

In fact, a subtle point in pseudoPush protocols is to set the timeOut right: if the time-out is too long, clients will miss important events during the unconnected stage of the loop, and will have to catch up when reconnected. If the time-out is too short, the protocol will implement a busy loop, making many useless connections and clogging the network, even if there is no real data to transfer.

Busy loops with nothing new to transfer ("nothing happened, nothing happened, nothing happened, nothing happened, user pressed the 'P' key, nothing happened, nothing happened, nothing happened, nothing happened,..."), clearly impact on network performance and do not scale to a world wide size.

So although pseudoPush could be considered a temporarily satisfactory solution, eventually a new protocol will have to be invented for real push connection style. This could be done:

  • as a wholly new transfer protocol, with no direct connection with HTTP.
  • as a connection-oriented version of HTTP. Allowing connections to idle even when still active, and be resumed to life by both clients and servers. This could be done by exploiting and modifying the 1** status code family in HTTP and relaxing some strict rules on turn taking between clients and servers.
  • by identifying a suitable existing candidate among the hundreds that provide the desired functionalities.

Relations with existing W3C standards

Currently the W3C provides a number of nice and clear recommendations to express most needs of collaborative applications: RDF as a means to express meaningful snippets of data to be exchanged among collaborating partners, SOAP as the basic data exchange protocol to let updates and resources reach each collaborating partner, XLink to provide the basic glue to associate precisely the data and the positions in the resource where the data should be applied. WebDAV?, although not strictly a W3C recommendation, is close enough to W3C to be considered as an important step towards interoperable transmission protocols. Also the experience fallback coming out of Annotea could help in shaping the set of desired features clearly and precisely.

Some other W3C languages and protocols would be useful to deliver the desired results, but are languishing in the candidate recommendation limbo for (possibly) lack of interest and application. We believe they could be revived within a new framework such as collaboration services, where each specific characteristic could find new and unforeseen applications. Among them we would surely cite XPointer, XML Fragment and XML Inclusions, all of which could help in defining a safe and interoperable set of features for collaboration applications. Since these three languages all revolve around XML data, clearly their usefulness would apply mostly to XML-based data formats and structures. Fortunately, the current trend is to express more and more data types via XML, which would improve the success chance of these protocols, were they used in a collaborative environment.

  • XML Fragment (Cand. Rec. 12 Feb 2001) could be used as the atomic update element in XML-based resources. Each utterance would then include an XML fragment as the utterance payload.
  • XInclude (Cand. Rec. 13 Apr 2004) could be used to specify the kind of editing operation a collaborative editor (both text and multimedia) considers as its current utterance.
  • XPointer (the xpointer() scheme, the only really useful in this context, has been Cand. Rec. and is now a mere Working Draft 19 Dec 2002) could be used to precisely identify the point in the resource being worked in or about, the utterance would point to.

Dynamic re-negotiation of the agreement

One additional desirable feature of the collaboration protocols would the ability to re-negotiate the agreement during the conversation. By being able at any point in time to decide on new collaboration parameters would help usefulness, usability and flexibility of collaborative applications.

Users involved in a synchronous chat would then for instance be able to add a shared drawing board (creating a new conversation), or to save the conversation so far (transforming the chat into a forum), or to open up the number of authorized people, or to request local locks, etc.

Conversely, a synchronous collaborative editor could be made into an asynchronous one just by reissuing a global lock instead of local ones, etc.

We believe that dynamic re-negotiation of the agreement would be exactly the feature to show that all collaborative applications are in fact the same, and can transform into one another by simply changing some collaboration rules.

Per capire meglio l’utilità della rinegoziazione torniamo allo scenario presentatato in precedenza. Ricordiamo che il mittente ha a disposizione una chat che gli permette di inviare messaggi testuali e allegati mentre il destinatario della proposta usa un editor collaborativo che supporta anche conversazioni testuali chat-like. Dopo che i profili delle parti sono stati analizzati dal server e i collaboratori si sono accordati sono passati alla collaborazione vera e propria scambiandosi messaggi testuali in real-time senza meccanismi di turno. Supponiamo che a questo punto il mittente decida di prendere parte anche alla collaborazione sul testo utilizzando un editor comune che non permette di inviare messaggi chat. Il fatto che il mittente utilizzi due applicazioni mentre il destinatario ne usi solo una che supporta entrambe le conversazioni non ha importanza ai fini della collaborazione. La fase della rinegoziazione consiste nell’invio da parte del mittente di un nuovo profilo che questa volta è fatto come segue:

<cap:proposal xmlns:cap="http://www.cs.unibo.it/CAP/1.0/" renegotiable="true"> 
    <cap:sender uniqueName="Luca1982">  
       <cap:name>Luca Rossi</cap:name> 
    </cap:sender>          
    <cap:request type="createNew"/> 
    <cap:conversation  
     id="a01"  
     favourite="true"  
     media="text/plain" 
     quality="1.0"> 
       <cap:isResource> 
          <cap:noLock> 
             <cap:multipleUtterance update="realPush" visibility="private"/> 
          </cap:noLock> 
       </cap:onResource> 
       <cap:transport> 
          <cap:transportProtocol version="1.1">HTTP</cap:transportProtocol> 
          <cap:securityProtocol version="3.0">SSL</cap:securityProtocol> 
       </cap:transport> 
    </cap:conversation>    
    <cap:conversation  
     id="a02"  
     favourite="true"  
     media=" application/octet-stream" 
     quality="1.0"> 
       <cap:isResource> 
          <cap:noLock> 
             <cap:multipleUtterance update="realPush" visibility="private"/> 
          </cap:noLock> 
       </cap:isResource> 
       <cap:transport> 
           <cap:transportProtocol version="1.1">HTTP</cap:transportProtocol> 
           <cap:securityProtocol version="3.0">SSL</cap:securityProtocol> 
       </cap:transport> 
    </cap:conversation>   
    <cap:conversation  
     id="a03"  
     favourite="true"  
     media="application/x-text-editor" 
     quality="1.0"> 
       <cap:onResource uri="http://www.sito.com/risorsa1"> 
          <cap:localLock grain="page" token="pool"> 
             <cap:multipleUtterance update="realPush" visibility="private"/> 
          </cap:localLock> 
       </cap:onResource> 
       <cap:transport> 
           <cap:transportProtocol version="1.1">HTTP</cap:transportProtocol> 
           <cap:securityProtocol version="3.0">SSL</cap:securityProtocol> 
       </cap:transport> 
   </cap:conversation>   
</cap:proposal>    

Come si può notare, questa volta le conversazioni sono tre perché oltre alle due conversazioni offerte dalla chat ora l’utente ha anche a disposizione la conversazione offerta dall’editor. Il profilo del destinatario è rimasto lo stesso ma a questo punto le parti condividono due conversazioni: quella testuale che era già in corso e la conversazione sul documento condiviso che si aggiunge alla prima.

-- ChiaraPilo - 25 Aug 2006
to top


Copyright © 1999-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding Fabio's Wiki? Send feedback