Re: Optional features considered harmful
At 7:57 PM 10/23/96, Tim Bray wrote:
>At 05:21 PM 23/10/96 -0700, Bill Smith wrote:
>>I find the introduction of "optional features" in XML most unfortunate
>Me too - I've been feeling bad ever since the vote. Maybe the WG can help
>us out here. Where we got to on the ERB was:
Yes, options are not a good thing. Let us rinse the taste of option stew
from out mouths (Thanks for the metaphor, Bill!).
>1. external text entities are a basic necessity for authoring (I want to
> validate my 700-page book without having to have it in a file) and
> they're not even that hard to do [once you've limited the system
> identifier repertoire, which we've done]. Arguably, without them,
> XML is a delivery-only toy language
While James' point that entities are not necessary is valid, I agree with
Tim's (later post) that they provide the "vendor-independent" way to do doc
management. Pace, Eliot, I think that with the synchrony restriction they
could prove to be a lot more useful than SGML entities have proven to be.
>2. external text entities are big-time bad news for a browser -
> particularly since browsers are moving in the direction of exposing
> the document structure to client-side logic. And in fact the
> jam-it-in-the-parse-tree semantic of text entities is not really
> the kind of transclusion you want in a browser.
I think the problem here is the assumption that the browser _must_ expand
the entity if it _can_ expand the entity. I advocate a different approach,
where a browser would have "transclude-if-convenient" semantics. So an
external entity reference might be rendered as an expandable link, like the
links in the old OWL product. The browser could automatically follow small
external entities, and link-ify large ones. This behavior is incompatible
with validation, but a non-validating parser would not care about this.
Since documents are parseable without a DTD, entities are too, so it's easy
to resolve an entity even after you have finished your first parse. You
will get better formatting if you retain the element stack + formatter
state variables in effect before unexpanded references, but even that is a
>So what we REALLY WANT is to say "Here is a feature that is intended
>for authoring and document management but look, boyo, don't you go
>asking client programs to do this!" I had proposed a side-step by
>saying you could only use <osfile> system identifiers for text
>entities, but this kind of smells like a kludge.
Is letting the client program do what it wants (including just popping up a
link) enough freedom to make browsers easy?
>Bob Streich had earlier spoken about server-mode vs. client-mode
>XML; is this anything more than an option by another name?
No, it's not, I'm afraid.
>I think I speak for the ERB when I say that we would welcome a way to
>throw out the optional bathwater without losing the text entity baby,
>and cheerfully reconsider the vote of the 23rd.
You've got my idea, for what it's worth.
>Cheers, Tim Bray
>firstname.lastname@example.org http://www.textuality.com/ +1-604-488-1167
RE delenda est.
I am not a number. I am an undefined character.
David Durand email@example.com \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________