twingle/doc/teps tep-0000.txt,1.1,1.2 tep-0104.txt,1.1,1.2

Update of /cvs/root/twingle/doc/teps
In directory alpha.oscom.org:/tmp/cvs-serv7041

Modified Files:
	tep-0000.txt tep-0104.txt 
Log Message:
Merging changes with Gregor

Index: tep-0000.txt
===================================================================
RCS file: /cvs/root/twingle/doc/teps/tep-0000.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** tep-0000.txt	8 Mar 2003 15:22:18 -0000	1.1
--- tep-0000.txt	8 Mar 2003 15:45:51 -0000	1.2
***************
*** 26,33 ****
  
   100    Basic XUL wireframe
!  101	Type system
   102	Model/view/controller architecture
   103	Editor widget
!  104	Server discovery
   105	Server-side support
   106	Client-side databases in profile directory
--- 26,33 ----
  
   100    Basic XUL wireframe
!  101	Server discovery
   102	Model/view/controller architecture
   103	Editor widget
!  104	Type system
   105	Server-side support
   106	Client-side databases in profile directory

Index: tep-0104.txt
===================================================================
RCS file: /cvs/root/twingle/doc/teps/tep-0104.txt,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** tep-0104.txt	8 Mar 2003 15:22:18 -0000	1.1
--- tep-0104.txt	8 Mar 2003 15:45:51 -0000	1.2
***************
*** 1,5 ****
  
! TEP: 104
! Title: Server discovery
  Version: $Id$
  Last-Modified: $Date$
--- 1,5 ----
  
! TEP: 101
! Title: Type system
  Version: $Id$
  Last-Modified: $Date$
***************
*** 10,14 ****
--- 10,189 ----
  Created: 07-Mar-2003
  
+ Abstract
+ 
+   Supporting many kinds of OSCOM servers, each capable of being
+   extended, will pose challenges for Twingle.  This document proposes
+   a type system based on RDF and XBL.
+ 
+ Problem
+ 
+   Although the field of content management is becoming more mature,
+   there are still few standards and little agreement on definitions of
+   terms.  This especially true in the OSCOM server projects, where
+   innovation remains rapid.  For instance, even the basic ideas of
+   folders and documents have different names in the different OSCOM
+   server projects and different capabilities.
+ 
+   Some of the OSCOM server projects have extensible architectures as
+   well.  Thus, different installations might have custom content types
+   defined that are unique to that site.
+ 
+   Twingle needs to accomodate this through a combination of addressing
+   issues and punting on issues.
+ 
+ Assumptions
+ 
+   The first step necessary is to find simplifying assumptions.  In
+   this case, the major point is that Twingle can deliver 80% of the
+   value by focusing on 20% of the content type capabilities of
+   servers.
+ 
+   How?  As long as the server can send back an RDF description of
+   every piece of content, and that RDF description contains a small
+   but important number of common metadata properties, then much of the
+   problem of efficient navigation can be addressed.  With just this,
+   Twingle can provide the following benefits over current CMS user
+   interfaces:
+ 
+     o Working between sites
+ 
+     o Browsing a tree of resources without returning to server
+ 
+     o Having multiple resources open simultaneously
+ 
+     o Newer navigation paths, such as "twenty recent changes", "by
+     author", or keyword searches
+ 
+   The second assumption is that there are two common types that most
+   others are derived from: collection and item.  Each of these will
+   contain a fairly common set of views that should be supportable by
+   any content type:
+ 
+     o Contents (for collections).  Note that this will allow add,
+     delete (with multiple selection), rename, cut, copy, paste, etc.
+     All of these operations are fairly slow and cumbersome in web
+     interfaces.  Twingle will do these quickly and asynchronously.
+ 
+     o Edit (for items)
+ 
+     o Preview
+ 
+     o Properties (for core metadata)
+ 
+     o Web manage (discussed in the next section)
+ 
+   Again, if it is true that all content types can easily support these
+   basic views, then Twingle is adding a lot of value, as these are the
+   important/frequent interactions for content authors.
+ 
+   Finally, we have the ultimate simplifying assumption: an escape
+   hatch.  The "Web manage" tab will give the custom view on a resource
+   that the CMS' regular browser interface provides.  If the content
+   author needs to do something unique to that content type in that CMS
+   server, the content author can easily and quickly find the place to
+   get there.
+ 
+ Type System Overview
+ 
+   Still, the remainder after these assumptions require a solution.
+   The way that data are retrieved and saved back to the server are of
+   particular importance, as getting a single way to do this (such as
+   DAV) is unlikely.
+ 
+   To tackle this, Twingle will provide an extensible type system.
+   Twingle will ship with support for major well-known types.
+ 
+ Type Definition
+ 
+   The RDF model of Twingle allows a resource to say that it is a
+   certain type.  For instance, a resource at
+   'http://some.where.com/somefolder/somedoc' might provide an RDF
+   property that says::
+ 
+     <oscom:resourcetype rdf:resource="urn:oscom:resourcetypes:document"/>
+ 
+   With this, the server is telling Twingle that this piece of content
+   is an instance of a well-known type, one defined by the URN
+   'urn:oscom:resourcetypes:document'.  This resource is built into
+   Twingle, and contains some metadata such as the title of the
+   resource type, the CSS style (to display an icon, and the kind of UI
+   widget to create (discussed below).
+ 
+   For custom types, the resource points to a resourcetype at a URN
+   they provide.  The handler for their type must be installed
+   separately.
+ 
+ XBL Bindings and Widgets
+ 
+   We now have the metadata for a piece of content.  We need some way
+   to display it to the user and handle server interactions.
+ 
+   Twingle will use Mozilla's XBL system for this.  With XBL you can
+   build composite UI widgets that contain state and behovior.  These
+   widgets can extend existing XUL widgets and internally contain
+   multiple widgets, including custom XBL widgets.  In fact, you can
+   inherit from other custom widgets.
+ 
+   In our case, we specifically need something to display when a
+   content author double clicks on an item in the navigation area.  For
+   Twingle, this means a new tab in the workspace with a tabpanel
+   containing tabs for each view of the resource.
+ 
+   The type system will define new elements that extend the XUL
+   '<tabpanel>'.  For instance, to display the above 'somedoc' document
+   resource, a custom element called '<documentviewer>' will be
+   defined.  This element extends tabpanel and contains a tabbox with
+   tabs for each view (Edit, Preview, Properties, Web Manage).
+ 
+   Each of those views are themselves custom elements
+   ('<documenteditor>',
+   '<documentpreview>','<documentproperties>','<documentwebmanage>').
+ 
+   The '<documentviewer>' widget also has state (the URL from which to
+   retrieve the data, the URL to which the changes should be put,
+   whether the text has changed, etc.) and behavior (how to save its
+   source to the server, how to retrieve its source from the server).
+ 
+   These widgets are also responsible for attaching themselves to the
+   workspace's tabs.
+ 
+   Since these widgets will be composed of fine-grained widgets
+   (editors, viewers, listings, etc.), building new widgets should be
+   straightforward and less prone to errors.  Also, making minor
+   distinctions (such as differences in ways that servers accept data)
+   can be encapsulated in these black boxes.
+ 
+   Finally, if a server or site really wants to exploit Twingle by
+   adding a custom view of a resource, they can extend Twingle by
+   installing a new XBL widget type.  For example, if a workflow
+   component wanted to have a workflow tab on each document, a
+   '<workflowdocviewer>' element could be created that extended
+   '<documentviewer>'.
+ 
+ Open Issues
+ 
+   Some kinds of collections, like a trouble ticket system, don't
+   accept any kind of content.  They only accept a single kind of
+   content item, a trouble ticket.  Providing a list of accepted
+   content types in a collection would improve the UI but significantly
+   increase implementation complexity.  However, passing the burden to
+   user (they try to add something and get an error message) isn't good
+   either.
+ 
+   Should the type system keep state internally (which would then be
+   divorced from the RDF model), or should all properties have
+   getters/setters which interact with the RDF model?  Some complexity
+   of dealing with RDF could be pushed to an XBL "superclass".
+ 
+   We are considering a broadcaster/observer architecture where
+   integrity of the "model" is tightly managed.  Actions don't modify
+   data directly or even through JavaScript methods.  Instead, they
+   broadcast events and subscribe to events.  Any state change would be
+   handled by a separate object, which would ensure the server gets
+   updated before updating the local model.  (Discussed in TEP 102).
+   This, however, would make widgets less autonomous and encapsulated.
+ 
  Copyright
  
    This document has been placed in the public domain.
+