Sure, but every site that has a significant document management requirement
is taking is *very* seriously because SGML is the 'maintenance format' for
these documents. The long term cost of maintaining data directly in HTML
is horrendous and I predict that it will break any organization that tries
it. The SGML-automated alternatives are far less expensive to run long term.
Anyway, I'd like to assemble a list of HTML products that disobey SGML rules,
possibly to arrange a boycott/smear-campaign/warning-label program of some
sort. Anyone that has any such information please forward it to me, or if
there is some repository of this information already, please let me know.
This could help the committee determine just how badly violated a particular
SGML tenet is, perhaps determine why, and propose an SGML-compliant solution
to the underlying problem/requirement. Then there will be no excuse for the
laziness and we can keep this flailing horror called the 'Web' on track to
become something useful for more than just printing badvertising.
> >What is nsgmls?
>
> An application of James Clark's sp parser, and a successor to "sgmls". It's
> freely available at places like the SGML archives at ftp://ftp.ifi.uio.no.
> I use nsgmls to validate HTML as SGML and translate the parser output into
> "browser HTML".
The main reason to stick closely to SGML is to leverage the existing parsers,
editors, industry-specific DTD standards, etc... if HTML deviates from this
it will be ten years before a credible hypertext knowledge maintenance
standard evolves. It is tough enough now just trying to figure out how to
maintain names of documents, with HTML anchors containing URLs working now,
more robust anchors containing URI/URNs on the way, and HyTime links possibly
coming down the pipe sometime.
-- Craig Hubley Business that runs on knowledge Craig Hubley & Associates needs software that runs on the net craig@passport.ca 416-778-6136 416-778-1965 FAX Seventy Eaton Avenue, Toronto, Ontario, Canada M4J 2Z5