WO2006054109A2

WO2006054109A2 - A system and method for storing revision information

Info

Publication number: WO2006054109A2
Application number: PCT/GB2005/004473
Authority: WO
Inventors: James Bayley
Original assignee: James Bayley
Priority date: 2004-11-22
Filing date: 2005-11-18
Publication date: 2006-05-26
Also published as: WO2006054109A3; GB0425668D0

Abstract

A method is provided for storing revision information in a data containing construct for containing data content, wherein the data containing construct is configured to contain a current data version only, and the method comprises modifying the data content so as to represent the revision information.

Description

A system and method for storing revision information

This invention relates to a system and method for storing revision information, for example in digital files and streams.

Files

Computers are used to store and process information which is often stored in data containing constructs such as files. All information is fundamentally stored as binary strings which are sequences of "1" or "0" values called bits. A file has a file name which uniquely identifies its information.

Files have a format which is a formally defined or a de facto way in which the binary string should be interpreted. For example, to interpret a "plain text file" with the ISO/IEC 8859-1 :1998 format the string should be divided up into a sequence of bytes (8 bits = 1 byte) and each byte is then compared to a look up table. For example the byte "01000001" represents the character "A".

Streams

A special type of data containing construct is a "stream". Examples of streams include television, radio, and internet broadcasts. Streams are also used extensively within computer systems. A stream is a flow of binary information from a stream source (e.g. a computer system) and to a stream consumer (e.g. a web browser).

Content

Both files and streams contain information which may be defined as data content. The file or stream format defines how the content should be decoded by a program. For example, the content of a plain text file is a string of bytes, each byte representing a character in the document.

Version and Revisions

When a file is first stored this is a first version of the file. Subsequently the file may be opened, changes made to the binary string and the file closed. The changed file is the second version of the file. The file name remains the same and there is only ever one binary string which has that name. Figure 1 illustrates this process. A first version 11 of the file is opened in an editor 15 for editing. During editing the editor 15 stores a current version 13 of the file and a revision history 14 of changes made to the file. The editor 15 may perform a save operation creating a second version 12 of the file. The second version of the file 12 replaces the first version 11.

Versions of streams are analogous to versions of files. For example, the application of the graphical equalisers to an audio input which created an audio stream would create a second version of the stream. Figure 2 illustrates a treatment of a generic stream. The first stream 21 is received by a stream processor 25, which may include a filter 24. Stream processor 25 applies the filter 24 to the first version 21 of the stream and outputs a second version 22 of the stream.

Annotations

Files and streams may be revised many times by the same person or system or by different people and systems in different locations and at different times. Sometimes it is necessary to create an annotation to the file or stream to facilitate a workflow. A problem with known systems is that some file formats do not allow revision information which may for example, comprise information about revisions, versions, revision history, version history and annotations to be stored within a file such that an editor cannot undo changes step by step or at all and that many formats which do allow this information to be stored do so in a proprietary manner that requires a particular editor to be used.

The lack of this ability reduces the functionality of editing tools and reduces the information about the file which is available to human users and computer processors. The same problem is encountered with streams.

For example, if a user edits a plain text file on a PC using a plain text editor, saves the file and closes the editor, the user cannot then undo their changes when the file is subsequently opened in the editor. This is because the text file format does not store revision information.

The source code of computer programs is usually plain text. Examples of programming languages include, without limitation: Java™, C#™, PHP, Perl and ColdFusion™. A source code control system stores previous versions of a file. Implementation of a source code control system can be a costly and time consuming exercise.

The invention is set out in the claims.

The present invention relates to systems and methods to install and recall revision and annotation information in digital files and streams. This information can be interpreted directly by the user or by the software tool. As a result, in the above example a plain text editor would be able to offer the undo feature on a newly opened document even though it did not support that functionality. In order that the invention may be more clearly understood, embodiments thereof will now be described with reference to the accompanying drawings, of which: figure 1 illustrates the relationship between a first version and a second version of a file; figure 2 illustrates a treatment of a generic stream; figure 3 illustrates a "save" operation; figure 4 shows a flow chart detailing the operation of an editor; figure 5 illustrates the separate components of processor step 86 shown in figure 4; and figure 6 illustrates a stream; figure 7 illustrates the concept of reverse delta; figure 8 illustrates an example of revisions made to a file; figures 9 A, B and C illustrate different representations of differences between a first version and a second version of the file shown in figure 8; figure 10 shows a flow chart detailing the operation of a source code editor; and figure 11 illustrates an annotation made to a version of a file.

Embodiments of the present invention provide a system and method for storing revision information such as revisions, versions, revision history, version history and annotations in a data containing construct such as a file or stream using, for example, steganographic techniques such that the content of the file or stream remains fit for purpose and the revision information can be saved in the file or the data storage format which do not support that functionality.

In the case where the data storage format does support the storage of revision information as described above an embodiment of this invention would provide an alternative method of storing such information using, for example, steganographic techniques such that the content of the file or stream remains fit for purpose and the revision information is accessible to any program which incorporates this invention.

Steganography

In cases where file formats do not support content storage with revision information; in order that a file having revision information stored there remains fit for purpose this additional data must be incorporated, for example by hiding it, within the file. Techniques for hiding data in files are commonly known in the field of steganography.

In cases where a file format does support content storage with revision information it is advantageous to store revision information in such a way that it is accessible to a plurality of programs which incorporate this invention. Steganography may be used to ensure the file remains fit for purpose.

Steganography is a well developed technology which includes many methods of hiding information in files so that it is not perceptible to the casual observer. It is often possible to store additional information within a file without rendering it unfit for its purpose. Steganographic techniques have been published which enable information to be hidden and extracted from many file formats.

Some examples of this include, dependent on the file format as appropriate:

• Adding spaces and tabs after the last line of text of a text file. These characters carry meaning but are invisible to the casual user.

• Hiding a text file in an image by slightly changing the value of bits representing the colours. The casual user cannot perceive the alteration but the hidden text can be extracted by a program.

• Writing information after the logical end of a file. For example a file format may define that information is only to be written to the first 1000 bytes. Information appended to the file after the first 1000 bytes would be hidden. Containing information within HTML comment tags; web browsers do not display such information.

• Containing information within a comment block in a file containing source code; the application which processes the file will ignore the text in the comment block.

Some steganographic techniques are harder to detect than others. A text file may be hidden in a 24 bit colour bitmap file by substituting the least significant bit of a colour component of each pixel with a bit from the text file. In this method of steganography the information may be regarded as hidden because it is very hard to detect other than by attempting to decode a text file from the least significant bit of the colour component of each pixel. Alternatively, a text file could be inserted into the comment block of a source code file. The text file would be very easily identified by opening the source code file in an editor, but the source code file would remain fit for purpose, where the purpose is to compile a program. Steganography is used in the present invention to ensure files remain fit for purpose, but in some applications it is also important that added revision information is also hidden. The requirements of the application dictate which type of steganography is appropriate.

Some steganographic techniques have limits as to how much data may be hidden within them. For example, in the case of a text file hidden in a 24 bit colour bitmap file by substituting the least significant bit of the colour component of each pixel with a bit from the text file, the number of bits in the text file that is hidden is limited to the number of pixels in the image. A larger text file may be hidden in the image file if the text file is first compressed. Compression will be discussed in more detail below.

As a result, it will be seen that, surprisingly, steganographic techniques can be applied to solve problems with known data storage formats. Figure 3 illustrates the manner in which steganographic techniques can be applied to incorporate revision information into a file according to an embodiment of the present invention. A first version 31 of a file is opened for editing in an editor 35. During editing, the editor 35 maintains a current version 33 of the file and a list of revisions or a revision history 34. During editing, the editor 35 may offer a user an undo function which allows the user to move through the revision history in a stepwise manner undoing each revision they have made to the open file. According to the present invention, the editor 35 has a "stegasave" function. When performing a stegasave, the editor 35 steganographically includes the revision history 34 into the current version 33 of the file and stores this as a second version 32 of the file, the second version 32 of the file replacing the first version 31 of the file. Accordingly, when the user initiates another editing session, the second version 32 of the file may be opened in the editor 35. Upon opening the file 32, editor 35 detects the presence of steganographically stored revision information in the file 30 and extracts this information. The editor 35 has a current version 33 of the file and a revision history 34.

A version of the file is preferably stored on a data storage device such as a computer hard disc or flash memory drive. The editor 35 is preferably a software program running on a computer attached to the storage device. During editing, the editor 35 preferably maintains the current version 33 of the file and the revision history of the file 34 in a temporary memory of the computer such as RAM. During editing the computer preferably displays the current version 33 of the file on a display device attached to the computer.

The revision information is preferably compressed by editor 35 prior to being stored in the second version 32 of the file. This advantageously increases the number of annotations and revisions or total amount of revision information which can be steganographically stored within a file or stream. The revision information is preferably represented using an XML representation to advantageously promote interoperability between software tools and to enable a single software tool to read the revisions and annotations made to many different file formats.

During the development of source code, it is often necessary to store a plurality of versions of the source code. Source code is typically stored in text files, which may be repeatedly edited. Each version may have amendments made by different users. It is possible that a particular user will make undesirable amendments to the source code, at which stage it will be desirable to roll back the version of the source to an earlier version. By storing earlier version information in the file as part of a steganographic save operation, it is possible to roll back a particular version of the source code to an earlier version.

Further, part of the additional information stored in a file may be author information. Author information allows a user to determine which user made which amendments to a file. This is particularly useful in the field of source code control, whereby a user, editor or author of a particular section of code may be identified.

A source code editor is provided which records a revision history during editing of a source code file, and which stores revision information in the source code file, comprising modifying the data content of the source code file so as to represent revision information in the source code file in a non-proprietary format. Advantageously, because the source code is stored a non-proprietary format, the source code file may still be compiled by a suitable compiler. Storing the revision information in the file in a non-proprietary format may require the application of a steganographic technique.

Encryption It is often necessary to ensure that information within a file can only be read by authorized users. One method of doing this is to employ encryption which scrambles the message so it is not readable by unauthorized users. The original message is clear text and the encrypted message is cipher text. A key is used to encrypt and decrypt the message. Encryption is a well developed discipline and examples include:

• Symmetric ciphers such as DES3 where the same key is used to encrypt and decrypt the message;

• Asymmetric ciphers such as RSA where different keys are used to encrypt and decrypt the message. These permit the publication of the encryption keys and are called Public Key systems.

Accordingly, the revision information can be encrypted for security. The software tool may also decrypt and present revised and annotated files to the user without user interaction. For example, an image file might contain two versions: one suitable for adults; and the other suitable for children. A web browser could render the appropriate image dependent on whether the user of the web browser was an adult or a child.

Alternatively, the proprietor of a file may then protect valuable information contained within the file. Examples of the benefits of encryption include that a content owner may encrypt the revision information using a secret key and may then publish an image on the Internet containing a full workflow history; and a member of the public will not be able to read his private information, but if the content owner subsequently wishes to edit the image the revision information is made available to him. A publisher of a software tool which can store revision information in a file may also encode a secret key within the tool, or remotely but accessible to the user, so as to ensure that revision information can only be viewed by users using their software tool. Alternatively, the user can enter a secret key into the software tool or a public key/private key system can be adopted. Alternatively again, a content owner may take a high value file and revise it to make it lower value, for example by blurring an image or disabling the future use of any computer program. The user may then take physical possession of all the information necessary to regenerate the high value content with the exception of an encryption key. The content owner may then sell the encryption key to the user in order to allow the user to undo the revision and review the high value content. Specific implementations of this may include removing and restoring high quality images such as maps or removing or restoring capabilities to a software program by modifying the executable code or the source code.

Compression

In addition, the revision information can be compressed. As noted above computers store information as strings of bits. The use of higher level file formats often result in data strings which contain more bits than are necessary to represent the information. Compression technologies use algorithms to reduce the number of bits used to store the information. The compression may be lossless in which case an inverse algorithm can restore the original content exactly, or lossy in which case the original content cannot be restored exactly. An example of lossless compression is the LZW algorithm used to create "zip" archives. An example of lossy compression is that used to generate JPEG images.

Figure 4 shows a flow chart detailing the operation of the editor 35 described above. A first version 41 of the file is opened at step 40 and a revision is made to the content at step 43 resulting in a modified current version 44 of the file having a different content, shown as content'. The file 44 is stored in temporary memory. Prior to performing a stegasave at step 45, the software tool processes revision information at step 43 to generate revision information, which is preferably in XML format. Processor step 46 preferably also comprises a compression step, wherein the XML revision information is compressed. Processor step 46 preferably also comprises an encryption step, wherein the compressed information is encrypted. The revision information is then steganographically encoded into the current version 44 of the file, and the file is stored as a second version 42.

Figure 5 illustrates the separate components of processor step 46 shown in figure 4. At step 55 data to be stored in the file is selected from: revisions 50, versions 51 , revision history 52, version history 53, and annotations 54. The selection may be made according to predetermined or user determined criteria. The criteria may be specific to the file type being edited. The selected data is converted to XML at step 56, and compressed at step 57. The data is then encrypted at step 58 to produce revision information 59.

An advantage of storing the revision information steganographically is that the content of the file remains fit for purpose. The advantage of this is that the file does not need further processing before being used in a player or viewer. For example, a file in the JPEG form containing steganographically stored revision information would still render in a web browser. Therefore, files encoded with additional revision information according to the present invention may be distributed and viewed in standard software appropriate for reading files of the relevant format.

Examples of revisions to other file types include without limitation:

• Cropping an image;

• Deleting a scene from a movie file;

• Changing the frequency balance in an MP3 audio file; and

• Changing byte values in an executable file.

The approach described above can be applied in the same manner to streams. Figure 6 illustrates the present invention as applied to a generic stream. A stream processor 65 receives a first stream 61 and additional information 63 which may comprise:

• at least one alternative version of the content in the stream, for example censored and uncensored content;

• subtitles;

• a caption commentary of text displayed below the main image; or

• different soundtracks to be played with attached video.

The first stream 61 and additional information 63 are received and processed by stream processor 65 to produce a second stream 62 containing revision information. The stream processor 65 may additionally comprises a selector 64, which selects a component of the additional information 63 to be stored within the second stream 62.

The stream processor 65 may additionally comprise a filter 66, which when applied to the first stream 61 produces an alternative version of the stream. Selector 64, may then steganographically encode the revision information such that a user receiving second stream 62 may select between a filtered and the original non-filtered content.

Revisions to streaming media examples include without limitation:

• Changing the frequency balance of an MP3 audio stream; and

• Changing the colour balance of a video stream.

For example, sound or video streams could be tailored for use with different equipment. A different frequency filter could be applied depending on the type of audio equipment used by a user. Versions or streams may be considered as a single stream containing multiple versions wherein a user selects which version to observe. As described above, the revision information may comprise a revision history defining the changes made to a first version of a file in order to generate a second version of the file. Alternatively, the revision information may describe annotations. An annotation may take the form of an instruction, additional information, or a comment. Annotations may be stored in an XML format and a software tool which reads and writes revision information to the file may have the ability to change the presentation of the revision information in terms of text, style and colour, for example. This function may be implemented using standard technologies such as cascading style sheets.

It will be appreciated the various approaches can be adapted for storing and implementing the revision information. A first technique is to apply a "reverse delta". The reverse delta between a second version of a file and a first version of the file is the change that would need to be made to the second version of the file to recreate the first version of a file. Figure 7 illustrates the concept of reverse delta. Revisions 73 made to the first version 71 of the file create the second version 73 of the file. The reverse delta 74 is calculated from the first version of the file 71 and the second version of a file 72 by a difference program. Usually, the reverse delta 74 operation recreates an exact copy of the first version 71 of the file from the second version 72 of the file. However, in some situations this recreation does not need to be exact. For example, if the first version of the file and the second version of the file were image files such as JPEG images it would be sufficient that the reverse delta when the delta was applied to the second version of the file produced a good approximation the first version of the file.

When a user makes a change to a file this is often done as a sequence of small changes called revisions. Figure 8 illustrates an example of revisions made to a file. In our example, the file PATENT.TXT is opened at step 83. A first version 81 of this plain text file contains a string "ABCDEF". At step 84 the "A" is deleted. This is a revision. This revision would result in a current version of the file shown at 85. At step 86 a "G" is appended to this string of characters; this is a second revision. The second revision results in the string of characters in the current version 87 of the file. A record of the sequence of the revisions is the revision history. At step 88 the current version 87 of the file is stored during a save operation to give a second version 82 of PATENT.TXT which contains the string "BCDEFG".

If a user has access to two versions of a file it is possible to generate a list of revisions between the two versions. There are many ways that these can be represented. For example the differences between a first version and a second version of PATENT.TXT could be represented as:

• Change (position 1 , " "), Change (position 6, "G") (illustrated in Figure 9A);

• Change (position 1, "B"), Change (position 2, "C"), Change (positions 3, "D") (illustrated in Figure 9B);

• Change (line 1 , "ABCDEF", "BCDEFG") (illustrated in Figure 9C).

Where the scope of the revisions is the entire difference between two versions the revisions are in effect the opposite of the reverse delta described above.

Figure 10 shows the operation of a source code editor. At step 100 a user, editor or author logs in such that their identity is recorded. At step 101 the editor opens a source code file "source.txt". Source.txt contains code 102. The user edits or modifies source.txt at step 103 to create code' 104. The source code editor records a revision history as described above and at step 105 this revision history is processed into revision information. The revision information also includes information identifying the user that logged into the system at step 100. At step 106, a steganographic save operation is performed which stores: revised code 107, which is equivalent to code'; and the revision information which includes user information in the file source.txt.

In an alternative source code editor, the revision information is generated by a reverse delta operation. In a further alternative, the user login step 100 is implemented during the steganographic save operation step 106. At login step 100, a user may be required to identify themselves by a username and password combination, or alternatively, the user may simply be required to provide label for the revisions that are about to be saved.

Examples of source code languages include, without limitation: Java™, C#™, PHP, Perl and ColdFusion™.

A source code control system is thus provided that stores previous versions of a source code document. Further, the source code control system provided may store user identity or label information in conjunction with revision information. The source code control system described may thus be easily implemented at relatively low cost.

Annotation can be any appropriate form and incorporated in any appropriate manner.

Annotations are usually (but need not be) pieces of information about the contents of a file. The defining characteristic of an annotation is that it can (but need not) refer to a position in the file or stream. There are many possible ways of making and specifying annotations. Examples include without limitation:

• An annotation to our sample file PATENT.TXT could be "3, change this letter to Z". In this example the annotation refers to the character in the file at position 3. Figure 11 illustrates an annotation 112 made to a version of PATENT.TXT 111.

• An annotation of a text file may be "This is all excellent"

• An annotation of a JPEG image might read "x1=100, x2=150, y1=100, y2=110, please darken this area"

• An annotation of an image file might be the latitude, longitude, and settings of the camera which made the image file

• An annotation of a MP3 audio file might read "1s, 10s, cut" • An annotation of a MPEG video file might read "5s, 10s, Fade" An annotation of an EXE file might read "pos = 1024, Page Boundary"

• An annotation of an audio stream might read "Fade Here" An annotation of a video stream might read "Cut Here".

The invention may be embodied in a software tool. The software tool allows a user to edit files and to stegasave files. The software tool may be a specifically designed program or may be a file editing program modified to perform stegasaves. Similarly the tool or a complementary tool can allow decoding/decrypting and presentation of a modified data construct including revision information.

As a result of the invention described above, the software tool allows a user to undo a revision. Each revision may be undone independently, in a stepwise manner or alternatively, all revisions made to a version of a file may be undone in order to allow a user to revert to a prior version of the file. In addition, the software tool allows a user to make additional revisions to a file and to store information describing these revisions with previously retrieved revision information in the file. The software tool also has the ability to insert, update or delete annotations stored within the file. The software tool may allow for protection of annotations and revisions from deletion or modification by an authorised user. The software tool also has an option to permanently incorporate revisions into a version of the file. This may be done on a per revision basis, or alternatively a user may select an option to store a version of the file without any revision information. Similarly, the software tool can permanently incorporate annotations into a version of the content. For example, the steganographically included annotation "cat" could be incorporated into a JPEG image by making the appropriate pixels black to represent the letters C, A and T. This process is sometimes called flattening the image. In addition, the software tool can revert to a previous version of the file, for example a certain version number or the version at a predetermined time, and restore all revisions and annotations made to the file subsequent to a previous version of the file being made, and offer the option of discarding or accepting all revisions or annotations made prior to a particular version. This will have the benefit of reducing the amount of information which must be steganographically encoded into the file. Additionally, the software tool can offer the option of extracting one or more versions of a particular file to at least one new file. Each of the new files may optionally contain the prior versions of the particular file. Presentation of the information can be governed by configuration information stored in the presentation tool or remotely accessed, for example applying standard technologies such as XSL, XSLT or CSS.

The software tool includes additional functionality. It can measure and report the capacity of the content to store additional information steganographically.

The software tool may generate and store a checksum or hash which may be used to identify a particular version of the content. In a situation where a plurality of users independently revise a file, the checksum or hash advantageously allows the point at which the versions branched to be easily detectable.

The software tool may allow a user to manually edit steganographically incorporated information by optionally showing or hiding the revisions and annotations to the user. For example, a HTML editor might by default, hide from the user this text:

<!--

Change this letter to "Z"

</Annotation>

In this case the annotations are incorporated steganographically because a WYSIWYG (what you see is what you get) editor would not show the information within the HTML comment mark up "<!--....->". This annotation does not render the Content unfit for purpose which is to be valid HTML. The software may additionally comprise a WYSIWYG editor having a text mode then the user would be allowed to edit the annotation directly.

The software tool may modify the content of the file for the purpose of creating a region of the content which is suitable to receive steganographically encoded information. For example, a JPEG image may have a grey border added to it. This border would not render the image unfit for its purpose of being viewed in a web browser on a grey background, but the border advantageously allows for the steganographic storage or revision information in the file. This function is of particular use where larger revisions are needed for small images. In a second example, a text document may have a comment block inserted at the end of the file into which the revision history of the file is written. In a third example, the sampling rate of an audio file may be increased to provide additional data within which revision information may be steganographically encoded.

The software tool additionally offers a user the ability to store and recall information, and change the format of the file during store and recall operations. For example:

• a rich image file format such as PSD could be saved as a JPEG image, all the information required to generate the rich image file may be stored steganographically in the JPEG;

• a DOC document may be stored as a text file, but all the information required to regenerate the DOC document is steganographically stored in the text file.

The software tool may additionally store information about the device that generated the content. In this case, the revision information comprises creation of information such as:

• the latitude and longitude of a digital camera at the time of creation of an image file; • the settings of a camera upon the creation of a digital image;

• the local time at the point of origin of a video feed; and

• the settings of a compiler which generated a file from source code.

The software tool may store additional information "on the fly". For example; When a user requests a JPEG image from the web server, the web server applies a blur filter to the image, the web server uses this invention to store the information required to remove the blur in the image; and the web server serves the new version of the image.

The revision information may be a reference to a location of information regarding revisions, versions, revision history, version history and annotations. Such a reference to a location may comprise a "Uniform Resource Indicator" or "URL" or hyperlink. The information regarding revisions, versions, revision history, version history and annotations is stored at the location which may be on a local storage device, or a remote server. Where the information regarding revisions, versions, revision history, version history and annotations is stored on a remote server, the information is preferably encrypted, and a corresponding key stored as part of the revision information, such that only a user in physical possession of the file may decrypt the revision information. The benefit of this is that the location reference and key may be a smaller amount of information to store in the second version of the file than revision information itself.

The present invention provides a new computer program which can store revision information in a file or stream such that the revision information can be subsequently extracted by the program to provide enhanced functionality to the user or provide the user with additional information. The user may be a human or computer process.

In an alternative embodiment of the present invention a patch, module, plug-in or extension for a computer program is provided which enables a conventional file processing program to be modified so as to be able to store, recall and display revision information within a file steganographically according to the present invention.

It will be appreciated that the invention can be implemented in any appropriate manner including software, hardware or firmware.

Commonly used file formats to which this invention could be applied include without limitation text formats such as "HTML", "XML", source code, image formats such as "JPEG", "GIF", "BMP", audio formats such as "WAV", "AIFF", "AU", "MPA", "MP3", "WAV", "GSM", "VMF", "FA", "VOX" and video formats such as "MPEG", "MOV", "AVI", "RAM" and "SWF" and executable formats such as "EXE" and "BIN". However, any appropriate file or data construct type can be modified according to the invention.

It will further be appreciated that any appropriate manner of storing the revision information can be adopted and that non-steganographic techniques can be used in appropriate circumstances.

Claims

1. A method of storing revision information in a data containing construct for containing data content, comprising modifying the data content so as to represent revision information in the data containing construct in a non-proprietary format.

2. A method as claimed in claim 1 , wherein the data containing construct is configured to contain a current data version only.

3. A method as claimed in claim 1, wherein the data containing construct is configured to contain revision information in a proprietary format.

4. A method as claimed in any preceding claim in which the data containing construct is one of a data file or a data stream.

5. A method as claimed in any preceding claim in which the content is data modified steganographically.

6. A method as claimed in any preceding claim further comprising modifying or deleting existing revision information.

7. A method as claimed in claim 6 in which the revision information comprises at least one of a temporary or permanent: revision, revision history, annotation or data content version.

8. A method as claimed in any preceding claim further comprising processing a data containing construct to identify capacity for storing revision information.

9. A method as claimed in any preceding claim in which the revision information is compressed.

10. A method as claimed in any preceding claim in which the revision information is represented in XML.

11. A method as claimed in any preceding claim in which the data content comprises an image.

12. A method as claimed in claim 11 in which the revision information is stored by modifying pixel colour values in the image, or in a border of the image

13. A method as claimed in any of claims 1 to 10 in which the data content comprises text.

14. A method as claimed in claim 13 in which the revision information is stored in a comment block.

15. A method as claimed in any of claims 1 to 10 in which the data content comprises audio.

16. A method as claimed in claim 15 in which the sampling rate is increased to allow storage of revision information.

17. A method as claimed in any of claims 1 to 10 in which the data content comprises one of video, or an executable.

18. A method as claimed in ay preceding claim further comprising storing additional information by modifying the data content so as to represent the additional information.

19. A method as claimed in claim 18 in which the additional information comprises information relating to configuration, conditions, location or time of a device storing the revision information.

20. A method as claimed in claim 18 in which the additional information comprises information relating to the manner in which stored revision information may be processed, for example a code sequence for identifying a predetermined revision.

21. A method as claimed in any preceding claim in which the revision information is stored in an encrypted form.

22. A method as claimed in claim 21 in which an encryption key is stored in a decrypting processor.

23. A method as claimed in claim 21 in which an encryption key is stored at a remote location accessible from a decrypting processor.

24. A method as claimed in claim 21 in which an altered version of the revision information is available in the absence of decrypting capability.

25. A method as claimed in any preceding claim further comprising reading the data construct at a processor and presenting data content therefrom.

26. A method as claimed in claim 25 further comprising presenting the revision information in one of editable or read-only form.

27. A method as claimed in claim 25 when dependent on claim 20 further comprising presenting the information in a format governed by the additional information.

28. A method as claimed in claim 25 further comprising presenting the revision information in a format governed by the construct reading processor.

29. A method as claimed in any preceding claim further comprising modifying a construct to create a revision information storage region.

30. A method as claimed in any preceding claim further comprising changing a data construct format upon modifying or reading the construct.

31. A method as claimed in any preceding claim comprising the step, at a modifying processor, of automatically carrying out a revision step and storing the revision information.

32. A method as claimed in claim 31 in which the data content is an image, and the revision comprises alteration of the image.

33. A method as claimed in any preceding claim in which the revision information includes at least one of an undo capability, a revert to previous version capability, and a discard intermediate version capability.

34. A method of accessing revision information in a data containing construct configured to contain a current data version only, and comprising reading modified data content representing revision information and extracting the revision information.

35. A method of presenting data content extracted from a data containing construct configured to contain a current data version only, and comprising reading modified data content representing revision information and providing corresponding revision capability.

36. A method of rendering a data containing construct configured to contain a current data version only suitable for storing revision information comprising modifying the construct to create a revision information storage region.

37. A method as claimed in any preceding claim, wherein the revision information is source code control information.

38. A method as claimed in any preceding claim, wherein the data content is source code.

39. A method as claimed in any preceding claim, wherein the data containing construct is for a source code editor.

40. A computer program configured to implement a method as claimed in any preceding claim.

41. A computer readable medium storing a program as claimed in claim 37.

42. A processor configured to implement a program as claimed in claim 37.

43. A revision information writer configured to implement a method as claimed in any of claims 1 to 36.

44. A revision information reader configured to implement a method as claimed in any of claims 1 to 36.

45. A revision information presenter configured to implement a method as claimed in any of claims 1 to 36.