I'm not following/analyzing each and every message posted to this mailing list
so this message may contain redundancies with former postings.
The following comments don't respect any order: they have been
written 'on the fly'. Comments are separated by '===' lines.
In Dave Ragget's HTML3 dtd (1st March 95):
========================
> <!ELEMENT TR - O (%cell)* -- acts like row separator -->
This comment is incredible ! TR ___IS___ a table row (as a set of cells)
and not a row separator; a such comment gives a definition equivalent to
the former P definition ! We all know the result of a such misunderstanding.
========================
> <!ENTITY % list "UL | OL">
Once again, why do you separate UL and OL ???? This keeps compatibility with
ancient GML styles but has no valid reason to exist any more. An ordered list
is a list; an unordered list is also a list; difference between UL and OL is
only an attribute (attribute can there be understood in its general meaning AND
in its SGML meaning). I clearly see this as an intrusion of layout style in a
SGML content.
What about :
<!ATTLIST LIST
....
liststyle (unordered|arabic|capalpha|lowalpha|bullet|dash|star) #IMPLIED
....
>
========================
> <!--======================== Math ===================-->
My god... You are reinventing the wheel... But a stone-age wheel.
Why don't you use the Euromath DTD for mathematics ?????
Or even ISO 12083 ?????
Furthermore, I can see plenty of problems with this part of the DTD:
* ATOP is absolutely awful !!!! How can you write such things in SGML ????
* ABOVE and BELOW have a layout meaning !!!!!!! The correct names should
be NUMERATOR and DENOMINATOR at least in a fraction !
* integrals should be defined in an ELEMENT !!! <INTEGRAL>
* you forget so many mathematical objects that this DTD is unuseable !
How can you convince LaTeX users that their zillions of formulas
are convertible into HTML easy-going ???? bra and kets (math meanings)
are NOT ONLY a succession of a '<' (char) objects separated by a comma
and a closing char '>'. A distribution is an OBJECT with a MEANING
containing (SGML meaning) OBJECTS.
* ....
This part of the DTD is at my point of view the worst thing in the whole
file. I am sorry to be so negative Dave, but my opinion is that a such math
DTD makes HTML run towards a catastrophe.
****PLEASE**** take a look at Euromath DTD. Contacts (maybe outdated):
EUROPEAN MATHEMATICAL TRUST
Ian R.Stone
University of Conterbury
irs1@ukc.uk.ac
fax: +44 227 452 196
Bjo"rn von Sydow
Chalmers Tekniska Ho"skolan, Sweden
sydow@cs.chalmers.se
========================
> <!--
> Note that table cells can include nested tables.
> Missing cells are considered to be empty, while
> missing rows should be ignored, i.e. if a cell
This kind of cell handling derives from GML. CALS dtd also use a
such mechanism for missing cells. When I implemented CALS tables
for Grif, this point was the very worst one I had to deal with.
Wysiwyg implementations of CALS tables are rare... I'm afraid
that a such rarity could be transmitted to HTML3...
Let's imagine a HTML instance containing a table. In this table a
row is not complete (a cell is missing) and there is a horizontal
span... Modifying the table in ordre to 1) remove the span 2) add
the missing cell (if not created at parsing time...) is not a simple
problem. Even if it looks simple. Believe me, I wrote a such code for
CALS... ;-(
> <!ATTLIST (%cell)
> %attrs;
> colspan NUMBER 1 -- columns spanned --
> rowspan NUMBER 1 -- rows spanned --
Your mechanism of span also complicates the problem for an editor.
Why don't you use id and idref for instance ?
========================
> message digest such as MD5 for the linked object and is needed
As we say in French, you want the butter and the money for the butter.
You are designing a SGML dtd. Not a network protocol. No other comment :-(
========================
> shape %SHAPE; #IMPLIED -- for shaped hotzones in FIGs --
Interesting approach. Is a SGML instance really the place for such an
information ? Answer is not obvious.
========================
> <SUB> and <SUP> are used for subscripts and superscripts.
Subscripts and superscripts are layout terms. Exponent and index are
objects names...
========================
> MARK is used as a generic marked range class, e.g. for change bars
This reminds me something I workd with 2 years ago: Vincent Quint from
IMAG designed at that time such "paired" elements. Their implementation is
not easy for a HTML editor. And I think using them won't be simple either...
My implementation in Grif was useable but there are so many holes where to
fall in that it makes this element a hard time for implementors... Just think
about overlapping paired elements !-)
========================
> Do we want to support arbitrary elements for link starts? This would
> involve adding HREF and related attributes to most elements.
YES !!!!!!! DO IT !!!!!! Oh please do it !
Why ? Because, for instance, it gives ID to SGML fragments in a HTML instance.
This allows a object-oriented database to store SGML fragments; and more, it
allows a such database to automatically retrieve information in a document !
Can't you see the power implied by a such implementation ? Imagine a HTML
document made of fragments edited by different authors remotely... You see
what I mean ?
I am very serious in these lines. I consider a such adding as a major
advance for HTML.
======================== no more comments today... ========================
==================== even if I still have a lot to say ====================
Dave, I do not neglect all the work done on a such DTD. This message is not
a flame.
I really see in HTML3.DTD some inconsistancies with the "spirit" of SGML and
terrible problems of mixing between content and layout. The kind of things I
saw in Netscape extensions.
HTML is a SGML application. As a SGML application, it ****MUST**** be
100% consistent with the norm.
I also see a math DTD incredibly far away from reality and SGML. This point
really scares me.
</Daniel>
-- Opinions contained in this message are strictly mine and do not reflect EDF point of view in any way.