Change Bars DTDlet

Terry Allen <terry@ora.com>

Mail folder: WWW Talk Jul-Oct 1993
Next message: Terry Allen: "Re Tables"
Previous message: Omy Ronquillo: "Tables"

Message-id: <199308062226.AA24177@ora.com>
From: Terry Allen <terry@ora.com>
Date: Fri, 6 Aug 1993 15:26:16 PDT
X-Mailer: Mail User's Shell (7.2.0 10/31/90)
To: www-talk@nxoc01.cern.ch
Subject: Change Bars DTDlet
Status: RO

<!--
On Changebars:

Jay Weber's idea of storing diffs outside the changed document
is interesting, but I think we want to be able to represent
versions within a document, too.

Dave Raggett proposes two new ROLE attribute values for 
the HTML+ EM tag, "deletion" and "addition," with a new
rendering hint, strikeout.  Aside from overloading
EM more, a point of some concern already, and aside from
the question of whether EM's role attribute ought to have
a delimited list of values, this won't work when revisions
cross tag boundaries.  A better mechanism is already in 
HTML+, namely CHANGED.  More on that below.

Lou Burnard brings to our attention TEI's (common?)
attribute REND, and suggests ADD and DEL tags with 
REND and RESP attributes, the latter evidently containing
the version number.  Here the tags are empty, and point
to anchors.

I suggest combining these two approaches.  The DTDlet below
uses paired empty elements to help avoid ID and IDREF errors
that could occur with CHANGED (which can have both ID and 
IDREF attributes), with the end element tag pointing to the
beginning element tag, as in CHANGED.  It also includes
an Altered element, which may be unnecessary.  The meanings
of the Version attributes are suggestions at this point.

SGML won't allow you to parse paired empty elements such as
these to see if they both exist, but if the begin element
tag (and its ID) is missing, the IDREF from the end element
tag will fail and an SGML error should be reported.  You 
could also parse nonSGMLlishly to check that every ID from
every begin element tag had a corresponding IDREF.  

These tags may occur anywhere, overlapping anyhow (or 
could when included in the proper content model of a 
parent DTD).  I think this set will accomodate all needs:
does it?  Can anyone think of an easy set of rendering rules
for likely combinations of these elements?  Does it matter
that you could place the end element tag before the begin
element tag in a document?

This document parses through sgmls.  -->

<!ELEMENT Beginadded	- O EMPTY>
<!ATTLIST Beginadded	
			id	ID 	#IMPLIED
			Version	CDATA 	#IMPLIED 
		-- Version in which text was first appeared -- >
<!ELEMENT Begindeleted	- O EMPTY>
<!ATTLIST Begindeleted
			id	ID	#IMPLIED
			Version	CDATA 	#IMPLIED 
		-- Version in which text last appeared -- >
<!ELEMENT Beginaltered	- O EMPTY>
<!ATTLIST Beginaltered
			id	ID 	#IMPLIED
			Version	CDATA	#IMPLIED 
		-- Version in which text was first altered -- >
<!ELEMENT Endadded	- O EMPTY>
<!ATTLIST Endadded
			idref	IDREF 	#IMPLIED >
<!ELEMENT Enddeleted	- O EMPTY>
<!ATTLIST Enddeleted
			idref	IDREF 	#IMPLIED >
<!ELEMENT Endaltered	- O EMPTY>
<!ATTLIST Endaltered
			idref	IDREF 	#IMPLIED >

<!-- END -->

-- 
Terry Allen  (terry@ora.com)
Editor, Digital Media Group
O'Reilly & Associates, Inc.
Sebastopol, Calif., 95472