Emails, blogs, or wikis - it's just permissions

The only difference between emails, blogs, wikis, and notebooks is permissions.

See the table below, which lists the document type, view permissions, and add permissions.

View	Add	Document
private	private	notebook
private	public	email
public	private	blog
public	public	wiki

Other than that, they can use exactly the same technology (RSS / Atom), and exactly the same authoring WYSIWYG methods.

Currently, they're all separate tools - I can't see that continuing. We're likely to see integrated online authoring suites to handle all of them together.

Internet Geometry

Web page layout, in HTML, follows the CSS box model. This assumes that everything on the page, including the page itself, is a box with vertical and horizontal sides - paragraphs, images, sections, text, etc.

This works pretty well until you try to include vector graphics - circles, curvey lines, polygons - and effects like rotation and skews. So SVG has defined its own, more sophisticated layout model based on absolute positioning and coordinate transformations - CSS can't be used to place SVG elements.

The SVG layout model is usually considered unimportant in its own right - the real emphasis is on SVG's elements, like circle, line and polygon. But I think differently - it transforms the internet's geometry.

SVG layout transforms HTML
The SVG layout model provides the missing pieces to the HTML layout model - rotations, skews, scaling, and length units.

After all, I might want just SVG's geometry, and not its elements (circles, polygons, etc). Consider the following compound XHTML / SVG fragment, which shows rotated text. Not possible with just HTML!
< h1 svg:transform="rotate(90)" > Hello < /h1 >

And how about the following use
< img svg:transform="translate(5,0)" src="http://www2.blogger.com/image.jpg" width="50%" / >
which finally allows web designers to offset their elements by an absolute amount (five pixels along the x-axis) from a percentage.

SVG and HTML layouts can even work together:
< img style="left: 5px;" svg:transform="rotate(45)" src="http://www2.blogger.com/image.jpg" />
The renderer should rotate the image, draw the smallest possible horizontal box around it, then place the left hand side of the box five pixels from the margin.

Note that for now, Opera, Firefox and Safari are all using the SVG foreignobject element to control transformations, rather than allowing simple use of the attribute as above. This seems bizarre to me - all that should be necessary is a namespace declaration, as per the examples above.

For the future: CSS4 and curvilinear coordinates...

CSS was designed to ensure independence of content from presentation. It's used to control HTML page layout.

For some reason, the SVG authors thought differently - there's no SVG CSS styles to control layout. But you can think of the svg:transform attribute as a super-powerful CSS positioning style. Adding it to CSS4 would introduce consistency and extra power for managing layout on the web.

And most proprietary graphics tools provide something that SVG can't - the ability to squish and distort images, like those curvy mirrors at the fairground. That's because SVG currently only allows linear coordinate transformations - i.e. rotations, translations, and skews.

More general curvilinear transformations could be added quite simply to SVG - for example, allowing radial coordinates. Apart from squishing images, this can be very useful to define paths - consider:

< h1 svg:transform="x,y + sin(x)" > This text fits to a sine wave < /h1 >
which fits HTML text to a sine wave, by mapping the x axis to itself and the y axis to the wave. Today, you can't do this with HTML text, and to do it with SVG text you would have to calculate a series of points on the path and then interpolate between them.

Geometry is important
Basic geometry might be more than two thousand years old, but it's still the foundation of graphics. SVG transformations can provide extra impact to web pages and much more freedom in placing elements. What's needed is a joined-up approach that combines the best of HTML and SVG layouts.

Records Management

In many industries - especially financial services - there are regulatory requirements to store data for various time periods. Examples include customer records, transaction records, financial statements, and even emails.

This adds up to a huge administrative challenge. Millions of records are created by many different systems - each has to be categorized, stored, regularly reviewed, available to retrieve at very short notice, then deleted as soon as the time period is up. Of course, in the meantime the legal definitions and time periods are regularly changed. And if you get it wrong, you're in deep trouble with regulators and establish a reputation in the press for bad management.

Part of the issue is that records exist in so many places - paper, database tables, email archives, file shares, mainframe storage. Every record should be tracked and tagged with a category, a creation date, an owner, and an expiry date.

Records Management on the web
Of course, a growing proportion of these records are now online - and this presents huge advantages:

• The URI: finally, a universal way to locate records.
• HTTP: a simple technique for transferring records, including standard descriptive headers
• Search Engines: sophisticated technology for crawling for records and for retrieving them
• HTML: a text format for records that can be quickly scanned and analysed, including meta tags

And of course, the web includes a cacheing system to manage expiry dates on every record.

There are two basic conclusions.

Firstly, you can expect Records Management Systems to become more and more like search engines - crawling the intranet for records, analysing them, categorising them, and flagging them when their expiry date is past.

And secondly, the best way to implement a records management solution is to migrate systems to the web - the basics are all built in!