Introduction Structure Architecture Conclusions

NovelleA collaborative open source writing tool software

Federico Gobbo & Michele Chinosi{federico.gobbo,michele.chinosi}@uninsubria.it

Universita dell’InsubriaVarese, Italy

Introduction Structure Architecture Conclusions

What we learned from hypertexts

The digital revolution and the medium of writing

Since the Web Era (1991), new forms and techniques of writingsemerged, whose structural traits are still unclear, and therole/distinction between authors and readers beging to collapse.

The optimists say: ‘hypertexts realize our postmodern anddecostructionist dream of an ‘opera aperta’ (open work)’.

On the contrary, the pessimists say: ‘authors have lost their powerin this openness’.

Introduction Structure Architecture Conclusions

What we learned from hypertexts

The main ideas behind Novelle

Our aim is to find a way to build new texts which is fully satisfyingfor authors/users/active readers and whose structure is clear, i.e.suitable for linguistic computation. These are the main ideas ofNovelle.

We feel that the problems faced by hypertexts are much more thesames of blogs and wikis. We didn’t want to reinvent the wheel, sowe gave a lot of attention of the known literature, in particular onhypertexts.

Introduction Structure Architecture Conclusions

What we learned from hypertexts

The analysis of terminology on hypertexts

The technical (Cunningham, McCloud) and philosophical (Nelson,Bolter, Landow) description of the known problems faced byhypertexts had helped us to design Novelle. We started fromterminology.

Terms as ‘chapter’, ‘page’ or ‘footnote’ become senseless in thenew texts, or they highly change their meaning. What seems to belost is the relations, the texture underpinning the text itself –etimologically, ‘texture’ and ‘text’ both derive from the late Latinterm textum, coined by the Roman Rhetorician Quintilianus.

Introduction Structure Architecture Conclusions

What we learned from hypertexts

Terms we adopt

Some keywords we found useful for our analysis:

web canvas instead of ‘web page’, much more clear and notdependent from printing, from web comics (McCloud);

lexias, i.e. autonomous units of a hypertext, form hypertexts ineducation (Bolter).

transclusion, i.e. a kind of quotation, but with the ability to followthe evolution of the original document (see later).

Introduction Structure Architecture Conclusions

Known problems and proposed solutions

Known problems as traced by Nelson, 1992

the framing problem, i.e. how to extract sub-collectionswithout loss of context information.

comparing complex alternatives, i.e. how to get parallel oralternative versions of the same document.

typology of links, i.e. how to order links avoiding confusion.

version control, i.e. how to keep track of the history of everydocument.

Introduction Structure Architecture Conclusions

Known problems and proposed solutions

Known problems as traced by Nelson, 1992

the framing problem, i.e. how to extract sub-collectionswithout loss of context information.

comparing complex alternatives, i.e. how to get parallel oralternative versions of the same document.

typology of links, i.e. how to order links avoiding confusion.

version control, i.e. how to keep track of the history of everydocument.

Introduction Structure Architecture Conclusions

Known problems and proposed solutions

Known problems as traced by Nelson, 1992

the framing problem, i.e. how to extract sub-collectionswithout loss of context information.

comparing complex alternatives, i.e. how to get parallel oralternative versions of the same document.

typology of links, i.e. how to order links avoiding confusion.

version control, i.e. how to keep track of the history of everydocument.

Introduction Structure Architecture Conclusions

Known problems and proposed solutions

Known problems as traced by Nelson, 1992

the framing problem, i.e. how to extract sub-collectionswithout loss of context information.

comparing complex alternatives, i.e. how to get parallel oralternative versions of the same document.

typology of links, i.e. how to order links avoiding confusion.

version control, i.e. how to keep track of the history of everydocument.

Introduction Structure Architecture Conclusions

Known problems and proposed solutions

Which problems are already solved?

the framing problem is not solved.

We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.

comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.

typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.

version control is solved by the wiki model of documenthistory, so we keep this solution.

Introduction Structure Architecture Conclusions

Known problems and proposed solutions

Which problems are already solved?

the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.

comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.

typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.

version control is solved by the wiki model of documenthistory, so we keep this solution.

Introduction Structure Architecture Conclusions

Known problems and proposed solutions

Which problems are already solved?

the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.

comparing complex alternatives is not solved.

A cue is givenby the document history model by wikis, but it works only ona chronological basis.

typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.

version control is solved by the wiki model of documenthistory, so we keep this solution.

Introduction Structure Architecture Conclusions

Known problems and proposed solutions

Which problems are already solved?

the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.

comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.

typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.

version control is solved by the wiki model of documenthistory, so we keep this solution.

Introduction Structure Architecture Conclusions

Known problems and proposed solutions

Which problems are already solved?

the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.

comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.

typology of links is not solved.

The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.

version control is solved by the wiki model of documenthistory, so we keep this solution.

Introduction Structure Architecture Conclusions

Known problems and proposed solutions

Which problems are already solved?

the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.

comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.

typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.

version control is solved by the wiki model of documenthistory, so we keep this solution.

Introduction Structure Architecture Conclusions

Known problems and proposed solutions

Which problems are already solved?

the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.

comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.

typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.

version control is solved

by the wiki model of documenthistory, so we keep this solution.

Introduction Structure Architecture Conclusions

Known problems and proposed solutions

Which problems are already solved?

the framing problem is not solved. We think the bestapproximation is to let the users be able to extractsubcollection on-the-fly, i.e. extractions are not permanent,they are view of lexias.

comparing complex alternatives is not solved. A cue is givenby the document history model by wikis, but it works only ona chronological basis.

typology of links is not solved. The (X)HTML standard(s) ofthe anchor tag is too generic to give a typology.

version control is solved by the wiki model of documenthistory, so we keep this solution.

Introduction Structure Architecture Conclusions

Known problems and proposed solutions

The wiki model of document history

creation

a very oldversion

the documenthistory timeline

an old version

the currentversion

the lastversion

a restorean edit

destruction

sandbox

Introduction Structure Architecture Conclusions

Ownership and licencing

The problem of ownership

In order to address the remaining problems, we found that we hadto make a choice for the problem of ownership.

The Blog Way. Blogs follow the annotation model, where a singlelexia is central and the others are comments, sometimes organizedin threads (“write once, read many”). Advantage: suitable for alot of licences.

The Wiki Way. Wikis follow an free-to-edit model, where everylexia is central: no authorship, no signature, no hierarchy (“writemany, read many”). Disadvantage: only GPL-like licences.

Introduction Structure Architecture Conclusions

Ownership and licencing

The problem of ownership

In order to address the remaining problems, we found that we hadto make a choice for the problem of ownership.

The Blog Way. Blogs follow the annotation model, where a singlelexia is central and the others are comments, sometimes organizedin threads (“write once, read many”). Advantage: suitable for alot of licences.

The Wiki Way. Wikis follow an free-to-edit model, where everylexia is central: no authorship, no signature, no hierarchy (“writemany, read many”). Disadvantage: only GPL-like licences.

Introduction Structure Architecture Conclusions

Ownership and licencing

The problem of ownership

In order to address the remaining problems, we found that we hadto make a choice for the problem of ownership.

The Blog Way. Blogs follow the annotation model, where a singlelexia is central and the others are comments, sometimes organizedin threads (“write once, read many”). Advantage: suitable for alot of licences.

The Wiki Way. Wikis follow an free-to-edit model, where everylexia is central: no authorship, no signature, no hierarchy (“writemany, read many”). Disadvantage: only GPL-like licences.

Introduction Structure Architecture Conclusions

Ownership and licencing

Solution: free licencing

We decided to let users/authors free to choose the licence of theirworks, as in case or narrative or creative works ownership is treatedas authorship, even by fellows of free culture (Stallman, Lessig). Inother words, each user owns his own lexias (as blogs).

So, we decided to implement every standard Creative Commons(cc) Licence version 2.0. Consequently, everybody is free tocomment everything, but freedom of everything may be denieddepending on the licence. This have to be chosen on lexia creation.

Introduction Structure Architecture Conclusions

Ownership and licencing

Solution: free licencing

We decided to let users/authors free to choose the licence of theirworks, as in case or narrative or creative works ownership is treatedas authorship, even by fellows of free culture (Stallman, Lessig). Inother words, each user owns his own lexias (as blogs).

So, we decided to implement every standard Creative Commons(cc) Licence version 2.0. Consequently, everybody is free tocomment everything, but freedom of everything may be denieddepending on the licence. This have to be chosen on lexia creation.

Introduction Structure Architecture Conclusions

Ownership and licencing

How to manage editing and create derivative works

creation the documenthistory timeline

an old version

the currentversion

creation of aderivative work

a new document history timeline

Introduction Structure Architecture Conclusions

Ownership and licencing

For people who don’t like pictures

A user may let others edit his work, i.e. no No-Deriv option in theCC licence. If so, he has the right to retain or refuse the attributionafter the edits – for comparison: wikis let only to restoredocuments along history, you can’t “fork contents”; nor blogs.

In this case, a new history timeline start and a derivative link willbe put to mark the derivation from the original work.

Introduction Structure Architecture Conclusions

Ownership and licencing

Transclusion: beyond quotation

the documenthistory timeline

the currentversion

an other document history timeline

a freezed quotation

transclusion

Introduction Structure Architecture Conclusions

Ownership and licencing

Again, for people who don’t like pictures

Every user may comment and quote works by others – max. 10%of the original document may be quoted, as in the Italian Law. Wecall the quoted text transclusion, following Nelson. Unlike thecut-and-paste text, a transclusion retains a link to recall theoriginal context (quotation link), so it never points to out-to-datedata.

Furthermore, a transclusion may let the author/user to be living,i.e. to be kept up-to-date along the history timeline of the originaldocument.

Introduction Structure Architecture Conclusions

Ownership and licencing

An up-to-date transclusion example

the documenthistory timeline

an oldversion

an other document history timeline

an up-to-date quotation

transclusion

the currentversion

Introduction Structure Architecture Conclusions

Ownership and licencing

From transclusion to a typology of links

A quotation link is a special case of the deep links, i.e. every linkthat let users change the context. A web page becomes a view oflexias, where relations/differences/comparison between lexias arerendered visually in a single canvas. The choice of the (CC) licencemay be a guide for the user.

So, we distinguish between shallow links, i.e. links in a single viewof lexias, and deep links, i.e. links that let users change view orcontext.

Finally, links to web materials out of our system will be marked asexternal links.

Introduction Structure Architecture Conclusions

Ownership and licencing

From transclusion to a typology of links

A quotation link is a special case of the deep links, i.e. every linkthat let users change the context. A web page becomes a view oflexias, where relations/differences/comparison between lexias arerendered visually in a single canvas. The choice of the (CC) licencemay be a guide for the user.

So, we distinguish between shallow links, i.e. links in a single viewof lexias, and deep links, i.e. links that let users change view orcontext.

Finally, links to web materials out of our system will be marked asexternal links.

Introduction Structure Architecture Conclusions

Ownership and licencing

From transclusion to a typology of links

A quotation link is a special case of the deep links, i.e. every linkthat let users change the context. A web page becomes a view oflexias, where relations/differences/comparison between lexias arerendered visually in a single canvas. The choice of the (CC) licencemay be a guide for the user.

So, we distinguish between shallow links, i.e. links in a single viewof lexias, and deep links, i.e. links that let users change view orcontext.

Finally, links to web materials out of our system will be marked asexternal links.

Introduction Structure Architecture Conclusions

New solutions to classic hypertext’s problems

Our solutions of open problems of hypertexts

the framing problem should be solved by deep links and webcanvas as views of lexias.

comparing complex alternatives should be solved bytransclusions and the document history model by wikis.

typology of links, i.e. shallow vs. deep (quotation, derivative)and external links should avoid chaos.

version control is already solved by wikis.

Introduction Structure Architecture Conclusions

New solutions to classic hypertext’s problems

Our solutions of open problems of hypertexts

the framing problem should be solved by deep links and webcanvas as views of lexias.

comparing complex alternatives should be solved bytransclusions and the document history model by wikis.

typology of links, i.e. shallow vs. deep (quotation, derivative)and external links should avoid chaos.

version control is already solved by wikis.

Introduction Structure Architecture Conclusions

New solutions to classic hypertext’s problems

Our solutions of open problems of hypertexts

the framing problem should be solved by deep links and webcanvas as views of lexias.

comparing complex alternatives should be solved bytransclusions and the document history model by wikis.

typology of links, i.e. shallow vs. deep (quotation, derivative)and external links should avoid chaos.

version control is already solved by wikis.

Introduction Structure Architecture Conclusions

New solutions to classic hypertext’s problems

Our solutions of open problems of hypertexts

the framing problem should be solved by deep links and webcanvas as views of lexias.

comparing complex alternatives should be solved bytransclusions and the document history model by wikis.

typology of links, i.e. shallow vs. deep (quotation, derivative)and external links should avoid chaos.

version control is already solved by wikis.

Introduction Structure Architecture Conclusions

A simple overview

The Architecture of Novelle

This is a basic scheme of Novelle multi-tier architecture

AJAX

Ruby on Rails

RDBMS

XML

DBMS / Filesystem

GUI

Introduction Structure Architecture Conclusions

Why XML for data?

XML, eXtensible Markup Language

We choose XML as language and meta-language because wewant to be able to save messages with their meanings.

XML is a W3C standard.

XML lets us extend and connect Novelle with otherapplications.

Storing separately data from their representations lets asystem run more efficiently and quickly.

Introduction Structure Architecture Conclusions

Why XML for data?

XML, eXtensible Markup Language

We choose XML as language and meta-language because wewant to be able to save messages with their meanings.

XML is a W3C standard.

XML lets us extend and connect Novelle with otherapplications.

Storing separately data from their representations lets asystem run more efficiently and quickly.

Introduction Structure Architecture Conclusions

Why XML for data?

XML, eXtensible Markup Language

We choose XML as language and meta-language because wewant to be able to save messages with their meanings.

XML is a W3C standard.

XML lets us extend and connect Novelle with otherapplications.

Storing separately data from their representations lets asystem run more efficiently and quickly.

Introduction Structure Architecture Conclusions

Why XML for data?

XML, eXtensible Markup Language

We choose XML as language and meta-language because wewant to be able to save messages with their meanings.

XML is a W3C standard.

XML lets us extend and connect Novelle with otherapplications.

Storing separately data from their representations lets asystem run more efficiently and quickly.

Introduction Structure Architecture Conclusions

Why XML for data?

XML suites our needs for the Repository

We use XML trees to store together data, metadata,messages and their meanings.

We tried to use other more classical solutions suchcommercial databases (e.g. Oracle) or open-source software(e.g. PostgreSQL, MySQL).

None of these solutions let us store efficiently our datastructure.

An Entity-Relationship schema can’t map exactly Novelle’sdata architecture.

Introduction Structure Architecture Conclusions

Why XML for data?

XML suites our needs for the Repository

We use XML trees to store together data, metadata,messages and their meanings.

We tried to use other more classical solutions suchcommercial databases (e.g. Oracle) or open-source software(e.g. PostgreSQL, MySQL).

None of these solutions let us store efficiently our datastructure.

An Entity-Relationship schema can’t map exactly Novelle’sdata architecture.

Introduction Structure Architecture Conclusions

Why XML for data?

XML suites our needs for the Repository

We use XML trees to store together data, metadata,messages and their meanings.

We tried to use other more classical solutions suchcommercial databases (e.g. Oracle) or open-source software(e.g. PostgreSQL, MySQL).

None of these solutions let us store efficiently our datastructure.

An Entity-Relationship schema can’t map exactly Novelle’sdata architecture.

Introduction Structure Architecture Conclusions

Why XML for data?

XML suites our needs for the Repository

We use XML trees to store together data, metadata,messages and their meanings.

We tried to use other more classical solutions suchcommercial databases (e.g. Oracle) or open-source software(e.g. PostgreSQL, MySQL).

None of these solutions let us store efficiently our datastructure.

An Entity-Relationship schema can’t map exactly Novelle’sdata architecture.

Introduction Structure Architecture Conclusions

Why XML for data?

Why RDBMS don’t fit our needs

The commercial solutions we tested haven’t native support forXML data except an emulation layer that maps XML treesinto E-R model to store data into tables, losing most of theexpressive power. These products also introduce a cost forpurchase and use them.

Other free RDBMS, such as the most famous MySQL orPostgreSQL, are compatible with XML data but they alsostore XML trees in a relational schema or map the entire XMLtree as BLOB (Binary Large OBject) storing it in one largetable.

Introduction Structure Architecture Conclusions

Why XML for data?

Why RDBMS don’t fit our needs

The commercial solutions we tested haven’t native support forXML data except an emulation layer that maps XML treesinto E-R model to store data into tables, losing most of theexpressive power. These products also introduce a cost forpurchase and use them.

Other free RDBMS, such as the most famous MySQL orPostgreSQL, are compatible with XML data but they alsostore XML trees in a relational schema or map the entire XMLtree as BLOB (Binary Large OBject) storing it in one largetable.

Introduction Structure Architecture Conclusions

Why XML for data?

Native XML databases

We tried using Xindice (by Apache Group), eXist, Ozone asnative XML databases.

While Ozone, as an Object Oriented XML native database,requires a large amount of memory for working on entire XMLtrees, Xindice and eXist are two more interesting projects.

Xindice has not been developed since april 2004, so it is verydifficult to adopt it for a new project.

eXist is more usable and stable, but it doesn’t implement fullXML standard and its performances are not so good (yet).

Introduction Structure Architecture Conclusions

Why XML for data?

Native XML databases

We tried using Xindice (by Apache Group), eXist, Ozone asnative XML databases.

While Ozone, as an Object Oriented XML native database,requires a large amount of memory for working on entire XMLtrees, Xindice and eXist are two more interesting projects.

Xindice has not been developed since april 2004, so it is verydifficult to adopt it for a new project.

eXist is more usable and stable, but it doesn’t implement fullXML standard and its performances are not so good (yet).

Introduction Structure Architecture Conclusions

Why XML for data?

Native XML databases

We tried using Xindice (by Apache Group), eXist, Ozone asnative XML databases.

While Ozone, as an Object Oriented XML native database,requires a large amount of memory for working on entire XMLtrees, Xindice and eXist are two more interesting projects.

Xindice has not been developed since april 2004, so it is verydifficult to adopt it for a new project.

eXist is more usable and stable, but it doesn’t implement fullXML standard and its performances are not so good (yet).

Introduction Structure Architecture Conclusions

Why XML for data?

Native XML databases

We tried using Xindice (by Apache Group), eXist, Ozone asnative XML databases.

While Ozone, as an Object Oriented XML native database,requires a large amount of memory for working on entire XMLtrees, Xindice and eXist are two more interesting projects.

Xindice has not been developed since april 2004, so it is verydifficult to adopt it for a new project.

eXist is more usable and stable, but it doesn’t implement fullXML standard and its performances are not so good (yet).

Introduction Structure Architecture Conclusions

Why XML for data?

XML Repository in the filesystem

Like most blogs and wikis, we choose to store Novelle XMLrepository on time-based filesystem structure. Our representation isa directory tree that reflects quite well our idea of history.

For every message Novelle stores three XML documents:

The message itself

Its past history

The filesystem directory tree

Introduction Structure Architecture Conclusions

Why XML for data?

XML Repository in the filesystem

Like most blogs and wikis, we choose to store Novelle XMLrepository on time-based filesystem structure. Our representation isa directory tree that reflects quite well our idea of history.For every message Novelle stores three XML documents:

The message itself

Its past history

The filesystem directory tree

Introduction Structure Architecture Conclusions

Ruby on Rails and AJAX

Ruby on Rails: an open-source web framework

The Ruby on Rails (RoR) framework lets us a quick developcycle for web applications without the need to rewrite commonfunctions and classes (DRY - Don’t Repeat Yourself).

It provides XML builder and gdiff/gpatch libraries. Inparticular:

gdiff/gpatch creates a patch from two files.

XML Builder offers a set of classes to menage XML files.

Introduction Structure Architecture Conclusions

Ruby on Rails and AJAX

Ruby on Rails: an open-source web framework

The Ruby on Rails (RoR) framework lets us a quick developcycle for web applications without the need to rewrite commonfunctions and classes (DRY - Don’t Repeat Yourself).

It provides XML builder and gdiff/gpatch libraries. Inparticular:

gdiff/gpatch creates a patch from two files.

XML Builder offers a set of classes to menage XML files.

Introduction Structure Architecture Conclusions

Ruby on Rails and AJAX

Ruby on Rails: an open-source web framework

The Ruby on Rails (RoR) framework lets us a quick developcycle for web applications without the need to rewrite commonfunctions and classes (DRY - Don’t Repeat Yourself).

It provides XML builder and gdiff/gpatch libraries. Inparticular:

gdiff/gpatch creates a patch from two files.

XML Builder offers a set of classes to menage XML files.

Introduction Structure Architecture Conclusions

Ruby on Rails and AJAX

Ruby on Rails: an open-source web framework

The Ruby on Rails (RoR) framework lets us a quick developcycle for web applications without the need to rewrite commonfunctions and classes (DRY - Don’t Repeat Yourself).

It provides XML builder and gdiff/gpatch libraries. Inparticular:

gdiff/gpatch creates a patch from two files.

XML Builder offers a set of classes to menage XML files.

Introduction Structure Architecture Conclusions

Ruby on Rails and AJAX

Ruby on Rails for the document history model

Using gdiff/gpatch we can implement our history model in aneasy way and saving space.

Moving across a history means to retrieve a fixed number ofsubsequent patches.

RoR doesn’t support XML native databases, so we temporarilyuse a RDBMS only for RoR needs.

Introduction Structure Architecture Conclusions

Ruby on Rails and AJAX

Ruby on Rails for the document history model

Using gdiff/gpatch we can implement our history model in aneasy way and saving space.

Moving across a history means to retrieve a fixed number ofsubsequent patches.

RoR doesn’t support XML native databases, so we temporarilyuse a RDBMS only for RoR needs.

Introduction Structure Architecture Conclusions

Ruby on Rails and AJAX

Ruby on Rails for the document history model

Using gdiff/gpatch we can implement our history model in aneasy way and saving space.

Moving across a history means to retrieve a fixed number ofsubsequent patches.

RoR doesn’t support XML native databases, so we temporarilyuse a RDBMS only for RoR needs.

Introduction Structure Architecture Conclusions

Ruby on Rails and AJAX

AJAX: Asyncronous Javascript And XML

AJAX is a web development tecnique for creating interactiveweb applications. It uses a combination of XHTML,Javascript, XML, CSS, DOM and the XMLHTTPRequestobject.

XMLHTTPRequest lets clients ask servers to give someparticular data using asyncronous handshake, while users canstill continue using the web application.

Ruby on Rails fully supports AJAX.

Introduction Structure Architecture Conclusions

Ruby on Rails and AJAX

AJAX: Asyncronous Javascript And XML

AJAX is a web development tecnique for creating interactiveweb applications. It uses a combination of XHTML,Javascript, XML, CSS, DOM and the XMLHTTPRequestobject.

XMLHTTPRequest lets clients ask servers to give someparticular data using asyncronous handshake, while users canstill continue using the web application.

Ruby on Rails fully supports AJAX.

Introduction Structure Architecture Conclusions

Ruby on Rails and AJAX

AJAX: Asyncronous Javascript And XML

AJAX is a web development tecnique for creating interactiveweb applications. It uses a combination of XHTML,Javascript, XML, CSS, DOM and the XMLHTTPRequestobject.

XMLHTTPRequest lets clients ask servers to give someparticular data using asyncronous handshake, while users canstill continue using the web application.

Ruby on Rails fully supports AJAX.

Introduction Structure Architecture Conclusions

Access Points

Access Points as a flexible model for navigation

In Novelle users can search through histories using a simplesearch engine.

The engine returns a list of meaning and a set of linksbetween them.

These links are represented with clickable images. Everyimage is itself a map that the user can surf and/or open toincrease details level.

Users can create new typed links between lexias orcomment/modify every existing lexia if these actions aregranted by the author.

These modifications are stored into the history of thedocument.

Introduction Structure Architecture Conclusions

Access Points

Access Points as a flexible model for navigation

In Novelle users can search through histories using a simplesearch engine.

The engine returns a list of meaning and a set of linksbetween them.

These links are represented with clickable images. Everyimage is itself a map that the user can surf and/or open toincrease details level.

Users can create new typed links between lexias orcomment/modify every existing lexia if these actions aregranted by the author.

These modifications are stored into the history of thedocument.

Introduction Structure Architecture Conclusions

Access Points

Access Points as a flexible model for navigation

In Novelle users can search through histories using a simplesearch engine.

The engine returns a list of meaning and a set of linksbetween them.

These links are represented with clickable images. Everyimage is itself a map that the user can surf and/or open toincrease details level.

Users can create new typed links between lexias orcomment/modify every existing lexia if these actions aregranted by the author.

These modifications are stored into the history of thedocument.

Introduction Structure Architecture Conclusions

Access Points

Access Points as a flexible model for navigation

In Novelle users can search through histories using a simplesearch engine.

The engine returns a list of meaning and a set of linksbetween them.

These links are represented with clickable images. Everyimage is itself a map that the user can surf and/or open toincrease details level.

Users can create new typed links between lexias orcomment/modify every existing lexia if these actions aregranted by the author.

These modifications are stored into the history of thedocument.

Introduction Structure Architecture Conclusions

Access Points

Access Points as a flexible model for navigation

In Novelle users can search through histories using a simplesearch engine.

The engine returns a list of meaning and a set of linksbetween them.

These links are represented with clickable images. Everyimage is itself a map that the user can surf and/or open toincrease details level.

Users can create new typed links between lexias orcomment/modify every existing lexia if these actions aregranted by the author.

These modifications are stored into the history of thedocument.

Introduction Structure Architecture Conclusions

What is done, what’s still to do

Novelle’s milestones

Make a concept map to organize goals and commonterminology for the team – done.

Test technologies in order to find out what may fit our needs– done.

Develop our first prototype with the basic data structure – inprogress.

Let users test our prototype with real data and real needs, inorder to have feedback about GUI and features – to do.

Adjust GUI and features. Publish Novelle as an open-sourceproject – to do.

Dig and extract sensible information automatically, thanks tothe well-structured context datas – to do.

Introduction Structure Architecture Conclusions

What is done, what’s still to do

Novelle’s milestones

Make a concept map to organize goals and commonterminology for the team – done.

Test technologies in order to find out what may fit our needs– done.

Develop our first prototype with the basic data structure – inprogress.

Let users test our prototype with real data and real needs, inorder to have feedback about GUI and features – to do.

Adjust GUI and features. Publish Novelle as an open-sourceproject – to do.

Dig and extract sensible information automatically, thanks tothe well-structured context datas – to do.

Introduction Structure Architecture Conclusions

What is done, what’s still to do

Novelle’s milestones

Make a concept map to organize goals and commonterminology for the team – done.

Test technologies in order to find out what may fit our needs– done.

Develop our first prototype with the basic data structure – inprogress.

Let users test our prototype with real data and real needs, inorder to have feedback about GUI and features – to do.

Adjust GUI and features. Publish Novelle as an open-sourceproject – to do.

Dig and extract sensible information automatically, thanks tothe well-structured context datas – to do.

Introduction Structure Architecture Conclusions

What is done, what’s still to do

Novelle’s milestones

Make a concept map to organize goals and commonterminology for the team – done.

Test technologies in order to find out what may fit our needs– done.

Develop our first prototype with the basic data structure – inprogress.

Let users test our prototype with real data and real needs, inorder to have feedback about GUI and features – to do.

Adjust GUI and features. Publish Novelle as an open-sourceproject – to do.

Dig and extract sensible information automatically, thanks tothe well-structured context datas – to do.

Introduction Structure Architecture Conclusions

What is done, what’s still to do

Novelle’s milestones

Make a concept map to organize goals and commonterminology for the team – done.

Test technologies in order to find out what may fit our needs– done.

Develop our first prototype with the basic data structure – inprogress.

Let users test our prototype with real data and real needs, inorder to have feedback about GUI and features – to do.

Adjust GUI and features. Publish Novelle as an open-sourceproject – to do.

Dig and extract sensible information automatically, thanks tothe well-structured context datas – to do.

Introduction Structure Architecture Conclusions

What is done, what’s still to do

Novelle’s milestones

Make a concept map to organize goals and commonterminology for the team – done.

Test technologies in order to find out what may fit our needs– done.

Develop our first prototype with the basic data structure – inprogress.

Let users test our prototype with real data and real needs, inorder to have feedback about GUI and features – to do.

Adjust GUI and features. Publish Novelle as an open-sourceproject – to do.

Dig and extract sensible information automatically, thanks tothe well-structured context datas – to do.

Introduction Structure Architecture Conclusions

What is done, what’s still to do

Thanks

We wish to acknowledge Massimiliano Pepe for his collaboration.

Attribuzione - Non Commerciale - Condividi allo stesso modo 2.0 Italia

http://creativecommons.org/licenses/by-nc-sa/2.0/it/

You may have this file here: http://purl.org/net/fgobbo

Questions?