lets-talk-planning — Planning Features for New Initiatives

[Ian B. <ie...@tf...>]

So, 
We've started building a prototype messaging structure that could
encompass traditional threaded discussion, but should also be able to
express and represent and conversation structure.

The components of this structure fall into the groups, a base level data
structure, a data transformation layer and a presentation layer. The
base level data structure is expressed as XML, the result of the data
transformation layer is also XML and the result of the presentation
layer is targeted at the presentation device. ( if a browser it will be
html or xhtml ). 

We will be using XSLT transformations and style sheets to transform
between the components in the structure. 

The base level data structure.

I see the base level data structure as being made up of 2 parts. The raw
xml "message" files and header files. Raw xml message files will contain
a message oriented namespace and then any number of additional
namespaces focused on the domain of the message in question. Hence if we
are dealing with a medical discussion, the namespace list might contain
a subset of HL7 or Snomed-CT (if there is such a schema). In the library
context, we might include a Dublin Core or RDF namespace. 

It is best to think of a message as a container for message content,
with some standardised tags that address the identifification and
organisation of the message.

In the case of threaded discussion the standardised tags include
representations of "messageid", "parentids" "childrenids" and "content"
an the discussion specific namespace would include "postedby",
"moderated", "forumid", "threadid", "subject", "messagebody". If there
were attachments then we might also include a separate namespace for
attachments.

Eg
----------------------------------------------
<msg:message xmlns:msg="http://www.lets.cam.ac.uk/ns/message.xsd" 
 
xmlns:td="http://www.lets.cam.ac.uk/ns/threaded_discussion.xsd" 
 
xmlns:att="http://www.lets.cam.ac.uk/ns/url_attachements.xsd"
 		 msg:id="12312">
	<msg:parents>
		<msg:parent msg:parentid="1231432" />
		<msg:parent msg:parentid="1231434" />
		<msg:parent msg:parentid="1231435" />
		<msg:parent msg:parentid="1231436" />
	</msg:parents>
	<msg:children>
		<msg:child msg:childid="2111" />
		<msg:child msg:childid="2113" />
		<msg:child msg:childid="2112" />
		<msg:child msg:childid="2115" />
	</msg:children>
	<td:forum td:id="21" />
	<td:thread td:id="3211" />
	<td:subject>How long is a string ?</td:subject>
	<msg:content>
		<td:messagebody>
Through the ages this is a question often asked, but does anyone have an
answer ?
		</td:messagebody>
		<att:attachment
att:url="http://www2.caret.cam.ac.uk/dspace/handle/1766/22"
att:name="The complete works of Plato" />
	</msg:content>
</msg:message>
--------------------------------------------

This is just an example, and I'm certain its got some errors in it, but
it expresses the concept. Each message is a separate file that contains
a base namespace that classifies it as a message. It also contains a
number of other namespace that classify it within the domain which the
message is addressing.

The data transformation layer will take a number of these message
documents, and transform them into a number of XML views of the message
documents selected. The message documents that are selected may be
selected by Xquery expressions or by reference to the header document.

Header Document
===============

The header document is an XML document in the base level data structure
that defines a collection of message documents relating to a specific
application. In threaded discussion it is likely that the header
document would collect messages within threads or possibly forum.

In a reviewing environment, the header document would collect together
the original document set for review, the discussion or comments on
those documents, and perhaps some ranking/rating ot the document.

In a rotisserie environment, the header document might collect and group
messages at different levels with in the rotisserie. The rotisserie
document would define the deadline dates for submission, the expose
dates, the number of messages per user at each stage, etc etc etc, hence
expressing some of the operational functionality of the collection.

Again the header document will have a base level namespace that enables
it to operate as a header, and a number of namespaces that address
specific functionality within domains addressed by the header document.

Eg

<msg:header xmlns:msg="http://www.lets.cam.ac.uk/ns/message.xsd" >
             xmlns:h2o="http://www.lets.cam.ac.uk/ns/h2o_operation.xsd" 
 
xmlns:att="http://www.lets.cam.ac.uk/ns/url_attachements.xsd"
		 xmlns:xlink="http://www.w3c.org/ns/TR/2005/xlink.xsd""
>
	<msg:name>A critical review of the Cambridge Tutorial
System</msg:name>
	<att:attachment
att:url="http://www.cam.ac.uk/somereferencedocument.pdf"
att:mime="application/pfd" att:name="Tutorial Structure with the
University" />
	<att:attachment
att:url="http://www.dfee.gov.uk/someotherdocument.pdf"
att:mime="application/pfd" att:name="Final Year results analysis"
/></msg:header>
	<msg:messges>
	<h2o:stage h2o:stagename="stage1" 
		h2o:deadline="25 January 2003 12:21:00 GMT"
h2o:release="30 January 2003 12:00:00 GMT" >
		<h2o:remiders h2o:type="GentNag.html"
h2o:frequency="12h" />
		<h2o:nmessages h2o:number="1 per user" >
			<h2o:stagemessage h2o:user="ian">
				<msg:message
xlink:uri="/messagestore/[msg:messgeid=23221]" />

			</h2o:stagemessage>
			<h2o:stagemessage h2o:user="john" >
				<msg:message
xlink:uri="/messagestore/[msg:messgeid=2221]" />

			</h2o:stagemessage>
			<h2o:stagemessage h2o:user="mike" >
				<msg:message
xlink:uri="/messagestore/[msg:messgeid=2323221]" />

			</h2o:stagemessage>
			<h2o:stagemessage h2o:user="judy" >
				<msg:message
xlink:uri="/messagestore/[msg:messgeid=25421]" />

			</h2o:stagemessage>			
		</h2o:nmessages>	
	</h2o:stage>
	<h2o:stage h2o:stagename="stage2" 
	h2o:deadline="25 Feb 2003 12:21:00 GMT" h2o:release="30 Feb 2003
12:00:00 GMT" >
		<h2o:remiders h2o:type="GentNag.html"
h2o:frequency="12h" />
		<h2o:nmessages h2o:number="1 per user" >
			<h2o:stagemessage h2o:user="ian">
				<msg:message
xlink:uri="/messagestore/[msg:messgeid=23221]" />

			</h2o:stagemessage>
			<h2o:stagemessage h2o:user="john" >
				<msg:message
xlink:uri="/messagestore/[msg:messgeid=2221]" />

			</h2o:stagemessage>
			<h2o:stagemessage h2o:user="mike" >
				<msg:message
xlink:uri="/messagestore/[msg:messgeid=2323221]" />

			</h2o:stagemessage>
			<h2o:stagemessage h2o:user="judy" >
				<msg:message
xlink:uri="/messagestore/[msg:messgeid=25421]" />

			</h2o:stagemessage>			
		</h2o:nmessages>	
	</h2o:stage>
	</msg:messages>
</msg:header>


Again this is total fiction, but it demonstrates the idea.



Transformation Layer
====================

The transformation layer uses the message documents and header documents
as source and XSLT as transforms to create XML views that are relevent
to the area being addressed.

Presenation Layer
=================

The presenation layer takes both the raw base xml and the output of the
transformation layer to create a view suitable for the browser (
whatever the device is )


Ian