Re: Permitting non-indirect links

At 12:16 16/1/97 -0500, David G. Durand wrote:

>I'm not sure how HoTMetal is doing against Front Page and its ilk, but
>that's not really the question. 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.

>>The fact that URL definitions using ID locators is more verbose than doing
>>an entitiy declaration is irrelvant to users. The IDs and associated
>>declarations will be generated automatically by the editor without user
>>intervention. The question is whether browser recognition of entity
>>declarations takes longer than browser resolution of IDs. If the entity
>>declarations have to be read as part of the DTD I would contend that at
>>browser level HyTime location addressing may be faster than entity resolution!
>
>The code to support the two is _very_ different in size and complexity, and
>the incremental benefit of adding that complexity is an arguable
>improvement in the elegance of the markup, and no improvement in expressive
>power. I'm still completely unconvinced.

I'm sorry, the code to support them has to be built into the system in any
case as you have to decompose the URL to be able to handle its component
parts when you get them. 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.
----
Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK 
Phone/Fax: +44 1452 714029   WWW home page: http://www.u-net.com/~sgml/

Received on Friday, 17 January 1997 13:10:42 UTC