Acceptance of XML (Seconding Bill Smith's posting)

At 7:22 PM 10/1/96, Bill Smith wrote:
>I've been following the discussion on the various topics and am concerned that
>in dealing with interesting details, we are ignoring the even more interesting
>"big issue" - acceptance.

>....

>HTML is an obvious lesser language. SGML is superior and I support it.

   Hear Hear to both comments.

>I am strongly in favor of designing initial XML such that it adds minimally to
>the complexity of HTML. Arbitrary structure and semantic information are
>sufficient. Marked sections, processing instructions, text entities, complex
>RS/RE rules, and the like are not required and will delay or prevent
>acceptance.
>We should avoid them. ISO 8879 conformance is not required although I see no
>reason to gratuitously preclude it.

I think that we can add complexity to HTML when it gives a lot of power.
For instance, I think some forms of entity add enough real power in
document management that it is worht the price. And the price need not be
paid by the peson who is not using entities. Easy to implement, useful
features that can be ignored if not wanted are not the problem. Intrusive
features that change current expectations are a problem,

I agree with you about the conformance issue, although that is not the way
the charter is written. I think that any compaitibility required complexity
or change to common (HTML, I'm afraid) practice needs to have a visible,
easy to understand payoff in _user power_. SGML compatibility does inf act
give a lot of power, but it's neither visible nor easy to understand.

>XML should be extensible and we should expect that it will evolve - perhaps
>rapidly. The Web community will expect (demand) no less. As the HTML, no XML
>community develops new requirements, solutions can be rapidly uncovered and
>presented using SGML as a warehouse. This group, or a follow-on would be
>viewed
>as responding to needs rather than dictating a complex, difficult to implement
>standard.

   This is a good argument for some kind of instance-like DTD syntax. It is
easier to add new features (even meta-features) in the guise of "adding a
new tag." I'm talking salesmanship, not technical reality here, so don't
jump down my throat about this.

    Let's keep end-user benefit in mind. A completely 8879-incompatible
syntax that allowed for extensible markup languages and (optional) document
grammars would still improve the state of the web 10,000-fold, or more!
Reality dictates, however that it look and feel like HTML, no matter how
divergent the underlying semantics really are. Look at the success of
C-like languages for anything-at-all versus any new syntax you can think
of. People want to feel that they are leveraging their knowledge, not
learning something new.

    -- David

RE delenda est.

--------------------------------------------+--------------------------
David Durand                  dgd@cs.bu.edu | david@dynamicDiagrams.com
Boston University Computer Science          | Dynamic Diagrams
http://www.cs.bu.edu/students/grads/dgd/    | http://dynamicDiagrams.com/

Received on Wednesday, 2 October 1996 11:05:25 UTC