(my last word on) Permitting non-indirect links

At 3:22 AM 1/17/97, Martin Bryan wrote:
>At 12:16 16/1/97 -0500, David G. Durand wrote:
>Currently we have a single href attrribute.
>>We must continue to allow that simplicity. URL syntax may not be much good,
>>but it is _not_ going away any time soon. Any multiple attribute solution
>>will be _additional syntax_. If we are going to add syntax, it must enable
>>something that would _could not_ do without that syntax. All the arguments
>>we have had about convenience have not yet shown such an advantage.
>
>This is where we fundamentally disagree. The URL syntax does not describe a
>"single attribute". It defines a set of components and shows how they can be
>concetenated into a single string that must be decomposed on receipt into
>the component parts, each of which must be processed separately. The href
>attribute is simply a container in which the concatenated parts of a URL are
>transmitted. Do not confuse the transmission container with the contents of
>the envelope. What I am arguing for, as a devil's advocate, is the adoption
>of a cleaner, if slightly more convoluted, design that recognizes the
>fundamental differences between the component parts of a URL and allows them
>to be managed separately.

So you are arguing that we should eliminate the "single URL syntax"
altogether? I think that that would be suicide for the levels of HTML
compatibility we should strive for (ie. different but familiar-seeming;
same low-level options remain almost as easy as they are in HTML).

If we change the syntax of simple direct links we will lose >50% of our
authoring audience right there. There will be no or few special XML tools
until there is a proven market, so that they don't help with _intial_
acceptance.

The "take your medicine, it's good for you" marketing approach is not a
good one.

> What is at question is whether pre-decomposition
>would offer any advantages. I'm not certain it does, but I want these points
>to be seriously thought about before we go blindly down a route that does
>not bring the gains that existing web masters are desperately seeking and
>which someone else will provide soon if we do not. Its a question of
>marketing. If XML is proveably safer to manage (note I did not say easier)
>then it will have a much much better chance of being accepted outside of the
>existing SGML community.

I think that we have something better: a management technique involving
entities that enables such "provably safer" management, and does _not
preclude_ the easier and compatible "href" linking-style. We could use
locsrc to get the same effect, but the combination of equivalent power,
additional verbosity, and an extra incremement of implementation difficulty
seems to argue against it. I tend to think that the kind of guarantee that
you are asking will appeal more to "the traditional SGML community" than to
the webmasters that I've met. People like extra power, but they don't like
having to unlearn things they already know (like hrefs).

   I'm done with this thread. I think we don't need additional syntax to
enable the functions you have convinced people would be good; no one else
seems to be listening; we agree on the arguments, and on the issues, but
disagree on the final solution.

   -- David

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                    \__________________________

Received on Friday, 17 January 1997 12:53:34 UTC