Re: Revision information for HTML documents

Ian S. Graham writes:
] I like this example also, but -- having initiated this whole INS/DEL 
] discussion,  would like to point out that computer code is not the 
] only place this INS/DEL is relevant -- in fact,
] code is probably the least important, in the long run. My particular
] interest was for legal or other text documents, where the reader needs 
] to see the insertions and deletions marked appropriately (struck out, 
] highlighted, etc) so I *need* information about the differences present 
] in some way in the document itself.  I also want these differences 

the document, in this case, is the RCS file (,v), and that contains
all the information you want, probably lots more, but that's mostly good.


] available to visually impaired users (text-to-speech, braille, etc),
] and eventually to authors using other languages. These requirements 
] really call out for some sort of ins/del semantic markup in the 
] (HTML or other language) document.

one problem as i can see is the granularity of RCS files, or rather
the `diff' program they use; they're line based and don't represent
movement of text.

i think the first restriction, however, can easily be solved by using
another diff program, with character granularity, the same as the
INS/DEL tags would give you.

movement of text, however, is more difficult to represent as it is
difficult to spot such things algorithmically knowing only the
resulting versions.


] There is a fine line between adding HTML/SGML functionality and moving
] that functionality over to applets. Applets are great, but they also make
] it easy to lose the platform-independence that is one of the strengths 
] of HTML/SGML.   Can I run this applet on a braille, or text-to-speech
] browser.  No.  Of course, I can create special applets for these 
] environments,  but then have to figure some complicated mechanism for
] selecting the applet based on the browser, etc etc. 

you're in no way bound to applets, but you need a modified WWW browser.
since your INS/DEL changes require WWW browser changes anyway, this
effort is the same if you use RCS ,v files or INS/DEL tags.


] Being an 'HTML minimalist' is fine -- I like to think I am one also --
] but the whole point of a markup system is to be able to mark up document
] content issues.  What is the point of 'minimizing' a document to the point
] where every document content-processing issue has to be implemented by 
] a separate encoding scheme (x-rcs, x-sccs, x-sgml-author-editor,.....),
] a new separate applet.

HTML wasn't designed to include revision information, but RCS ,v files
were designed to represent revision information in text files.  sooner or
later you have to give up trying to squeeze functionality into a
monolithic system, many would perhaps say we're already "later" with HTML
-- though i must say your proposed new tags may be appropriate if you
define appropriate to mean logical markup.  still, creeping featurism is
very bad in the long run, and we all want HTML to last a long time.

normally, you don't want to know all the revisions of a document, you
only want the last one.  if you, however want all the revisions, you'll
get another kind of document, a variant of the first one, in another
media type (application/x-rcs instead of text/html).

side note:  wouldn't it be better to have 'html' in the media type somewhere,
to tell the media type browser multiplexer (what a great name :) that it
should launch a HTML capable RCS browser?

another side note:  perhaps this whole issue of revision changes should
be moved up to the URN level; in addition to requesting specific versions
of documents, you could also request the delta between two versions?
a document that lives a long time can get a very large history, and
you really want to select which deltas you're interested in instead
of retrieving all of them.


] I'd rather first determine, by analysis of some general document editing 
] issues, whether or not ins/del/move/???? is a markup issue. If it is, then
] we can design the minimal number of elements required to do so, and *then*
] design applets that take advantage of this semantic content.

sure.  what general document editing issues are you talking about?

all i'm trying to do is compare the functionality of the RCS approach with
the new HTML tags approach, and if the former is a superset of the latter,
go for the former since it uses available technology and doesn't require
standards changes.  if

- the HTML tags approach gives you more functionality and
- you really need that new functionality
  (guess this is where your document editing issues come in)
- that new functionality can't be easily incoporated into a RCS
  (or similar) approach and

then i guess that's a good reason for changing HTML.


bye,
-- 
Bjørn Stabell <mailto::bjoerns@acm.org>
              <http://www.cc.uit.no/~bjoerns/>
              <fax:+4777644100>

Received on Monday, 18 December 1995 13:47:16 UTC