> > One opinion: browsers should be as robust as possible; however, to
> > help people make the document truly portable, there should also be
> > a validating parser tool available, perhaps built into the servers.
>
> I have long argued for an equivalent of lint and beatify for HTML.
> IMHO browsers should indicate if a document doesn't conform to the DTD,
> perhaps by a simple indicator light, along with an ability to get
> a report on the errors detected. I don't want the overhead of the
> server running this validation tool each time I retrieve a document
> though. This should be an offline job for the WebMaster of that server.
AGREE.
__________________________________________________________________________
> > Dave H
> peter
> > Likewise, I am concerned about the expressiveness of HTML+. There are
> > many document types today that can not be reproduced faithfully using
> > this specification; interactive catalogs, technical magazines are two
> > examples that will not be able to be done without significant compromise
> > to their design specifications.
>
> I don't think we can realistically expect to be all things to all people.
> At some stage we have to bring the axe down and say "this is what HTML++@
> will do, and this is what it will not do". So long as we document clearly
> what users cannot expect to do, we will have a stable platform for other
> and future developments.
Yes, any system will impose limitations. In the past and in talking
to people about the web, I have found that one common issue is
expressiveness. In pure semantic languages this issue is in the
size and range of the tag set. In SDL, it is the factors controlled
by the table of semantic styles (TOSS).
If the goal of HTML+ is to provide a more standard, computable, rational,
stable basis for what is done today, fine--the future will take care
of itself. On the other hand, if we are to look to the future, then we
must consider the limitations in light of the anticipated needs of the
future.
> > Many of those who will be funding the growth of the Internet (and other
> > networks) will be looking to reproduce their information in the visual
> > form they are used to. IF we wish this to be a tool used (and thereby
> > moved forward by) these types of applications then we need to consider
> > their needs.
>
> Consider, perhaps, but they are going to have to learn the facts of life.
> Concentration on visual-only documents will kill the whole concept stone
> dead. I know they're funders and we may have to kiss the right ass from
> time to time, but I don't see why we should compromise the structural
> validity of what we are doing just to please some semiliterates in govt
> or biz. They want a pictorial network, let them go help Ted Turner.
True enough, most of "those" people need to wake up to the true value
of their materials. I DO NOT ADVOCATE PS and or ACROBAT or anything like
that! However, we should also take care to not impose limitations that
are not of value to the implementation of a semantic/structure based
environment and tools.
I would hope a way could be found to maintain the "structural validity"
and provide control over style. We are trying to do both right now with
the COSE/Common Desktop Environment Help viewer.
_____________________
>
> [wysiwyg editors]
> > This is a fundamental issue. I would propose that you cannot reach
> > agreement as to what a good DTD is without agreeing to this aspect of
> > it usage. So, what will it be?
> > ___ Full support for hand tagging
> > ___ Limited support for hand tagging, limited support for specialized
> > editor
> > ___ specialized editor or tool
>
> I'm not clear what the issue of WYSIWYG editors has to do with a "good" DTD.
> You can use any SGML editor you wish with any DTD, as far as I know.
>
You can use any editor with any DTD assuming the DTD does not use
features (Link, Concur, short reference maps etc) that are not supported
by the editor. In adopting an old HP dtd to ArborText, Interleaf, and
FrameBuilder I found that the design of the DTD had a large impact on
the usability of the combined tool.
Two examples, our old DTD used every minimization trick in the book
(and a few that were not) resulting in literally dozens of
valid elements in most contexts. GUI menu systems are not good at
controlling that many choices and our authors became confused.
Another example is the choice of tag names. The original dtd had the shortest
tag names possible to minimize keyboarding. When put in GUI editors (that
do not map from GI to menu item) the odd order and cryptic names were a
problem.
Regards,
Dave H