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=20
] really call out for some sort of ins/del semantic markup in the=20
] (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 ma=
ke
] it easy to lose the platform-independence that is one of the strengths=20
] 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=20
] environments, but then have to figure some complicated mechanism for
] selecting the applet based on the browser, etc etc.=20
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 documen=
t
] content issues. What is the point of 'minimizing' a document to the po=
int
] where every document content-processing issue has to be implemented by=20
] 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 somewh=
ere,
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 editin=
g=20
] issues, whether or not ins/del/move/???? is a markup issue. If it is, t=
hen
] we can design the minimal number of elements required to do so, and *th=
en*
] 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 wit=
h
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,
--=20
Bj=F8rn Stabell <mailto::bjoerns@acm.org>
<http://www.cc.uit.no/~bjoerns/>
<fax:+4777644100>