Jon Knight writes:
 > On Fri, 6 Sep 1996, Daniel LaLiberte wrote:
 > > Rendering for humans is not the main purpose but it is a significant
 > > side benefit. The generality of the data structure is a much more
 > > important goal.

 > OK, so if we're talking about having a more general structure than META
 > in HTML 2.0 provides for, what was wrong with the DCES SGML DTD?

The SGML DTD plans have a few problems, in my opinion. First, the
SGML data structures are not easily renderable by existing browsers,
as the HTML data structure would be. But as I said, this
renderability is less important than the generality of the data
structure. But the SGML structures that I have seen, although
general, are not easily extensible. When the particular data
structure is defined in the DTD to the extent that field names are
element names, then there are two ways I've seen to extend the data
structure. You could extend the DTD, but this is moderately difficult
for normal users and it applies to the structure as a whole -
extending uses of types just at lower levels is difficult or impossible.

The second way to extend the data structure is by using a
loophole capability, which is much like the generic HTML data
structure I propose, where name value pairs are defined on top of a
generic structuring mechanism. I like this way better when it is
used throughout rather than as an asymmetrical add-on.

 > Why do we need this in HTML at all if its _not_ specifically for
 > rendering?

Because the HTML is *also* easily renderable. Furthermore, browsers
already parse HTML into an internal structure that facilitates
rendering (and rerendering as the screen size changes, etc) so they
could be changed to use the HTML data structure form as a data
structure more easily than adopting general SGML.

 > HTML is after basically a rendering oriented SGML DTD. What we're after
 > here is structuring so why not just use a clean DTD without having to
 > support all the bogosity of <CENTER> and <BLINK>?

We could define a clean DTD for just the parts of HTML that we want to
use for the data structure, and that would not include CENTER and
BLINK, but might include things like TABLE. But browsers would not
have to know about the DTD to still function correctly. The DTD would
be useful to applications that want to verify that the structures
conform, but this would be fairly useless because they would only
verify the generic structure (at the DL UL level), not the particular
TYPE of data that is built on top of the generic structure (at the
Dublin Core level). But tools for that high level verification could
also be built, given a formal type definition.

 > 3) Using HTML to hold some structured metadata (possibly including
 > Dublin Core) using <DL>..</DL>.

Not just <DL>...</DL>, and not necessarily that at the top level.
DL gives you a record structure, UL gives you unordered lists, etc.

 > This I still think is a bit odd. If
 > its just to be rendered, why does it need new elements/attributes?

It's not *just* to be rendered, and it needs a TYPE element to be self
describing. The TYPE element serves a similar purpose as the DTD in
the SGML data structuring plans.

 > If its for machine parsing of DCES elements why not just use the
 > HTML 2.0 style META embedding as in 1) or a LINKed document conforming
 > to the DTD in 2)?

Certainly META, LINK, and SGML are machine parsable, but the META and
LINK plans are insufficient by themselves and the SGML idea is too
much.

Actually, I'm not strictly opposed to the META, LINK, or SGML plans,
because they have their place. But I think the HTML data structure
fills a much larger niche more easily. It's an easier route to
deployment as well as being very powerful.

dan