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
luxury.

>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
>tbray@textuality.com http://www.textuality.com/ +1-604-488-1167

RE delenda est.
I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________
http://www.dynamicdiagrams.com/services_map_main.html

Received on Thursday, 24 October 1996 12:28:12 UTC