Re: ERB decisions on the LINKTYPE proposal

At 19:30 04.03.97 +0100, David Durand wrote:
...

I won't to respond all David's arguments, because Murray Altheim did an
excellent job of countering most of them. Let me just pick up on a few
points he didn't cover:

>If the Exoterica people claim that it's not well-defined enough to
>implement, I take that seriously. So my assertion has some support.

And I take even more seriously the fact that James Clark *has*
implemented it. Even more so considering the arguments raised by those
who think LINK has been rendered obsolete by DSSSL. (Now why would the
guy who practically rewrote the DSSSL standard turn around and
implement LINK, I wonder?)

To be honest though, I don't think citing authorities is a very productive
way of conducting a discussion. (Do you want me to start marshalling
Charles, Eliot and others in my support?) I too have a lot of respect
for the Omnimark people, but I don't consider people's arguments in a
vaccuum. If anyone were to have a vested interest in *not* supporting
standard mechanisms for generalised processing it would be vendors of an
SGML processing language that is well on its way to becoming a de facto
proprietary standard. (Not that I am accusing anyone of intellectual
dishonesty; everyone's opinions are to some extent formed by their
personal interests, as well as their experience and needs.)

>I don't believe that LINK solve the attribute attachment problem because it
>explicitly allows LINK attribute names to be the same as document attribute
>names -- so it just doesn't address the problem unless you mis-implement it.
>
>...
>
>I note that you didn't address the separate namespace issue, which is the
>real stumbling block in the current proposed application.

I said I didn't feel qualified to comment on how much extra difficulty
of implementation it would cause. I still don't, but I am grateful to
Steve DeRose for admitting that this isn't the major issue.

However, from a conceptual point of view, I think separate name spaces
is a great strength, precisely because it solves the problem of name
space collisions. Much cleaner than APPINFO "sda=sda" (or an implied
APPINFO "xml-link=xml-link") and another reason why the LINK-based solution
is preferable to multiple attlists.

>What does an element with XML-link="xlink" and the LINK-attribute
>XML-link="foobar" mean?

It means that the document designer has included an element type which
generally acts like an xlink, but that for a particular processing run
(governed by a particular processing specification, or LPD) should be
processed as if it were a foobar. More power, see?

(Or else it means someone screwed up, of course. But you can't ever
guarantee against that.)

>  Well, you came close to accusing him of fabricating the position in your
>original post... the words were "I find this argument so unlikely that I
>have it under suspicion of being vicarious." Maybe you meant something
>else...

I did indeed mean something completely different. (Is my English really
that bad?) What I wrote was:

>There remains the objection (brought to us second-hand by Tim) of
>"several members" of the ERB who "find the syntax [of the <!LINKTYPE
>technique], and the prospect of explaining it, repellent."
>
>I find this argument so unlikely that I have it under suspicion of being
>vicarious...

First of all, it was the *argument itself* I suspected of being vicarious.
As far as I was concerned, Tim was merely reporting the argument in an
objective manner. (I didn't know his own position at that point in time
anyway.)

Secondly, "vicarious" has nothing to do with fabricating positions. My
dictionary defines it as "deputed, delegated; acting or done for another".

My suspicion was that dislike of the syntax could not be the real
underlying reason for objecting to LINK, and subsequent discussion has
shown this to be the case (at least for Steve and Tim; it does appear that
this was Jon's principal objection).

>>* We do have a new construct which isn't in the November draft. However, it
>>  is just a one-production, simple wrapper around an existing construct.
>
>Michael responded to this already.

I haven't seen any contributions from Michael on this topic. Did I miss
something?

Best regards,

Steve

--
Steve Pepper, SGML Architect, <pepper@falch.no>
Falch Infotek a.s, Postboks 130 Kalbakken, N-0902 Oslo, Norway
http://www.falch.no/  tel://+47 2290 2733  fax://+47 2290 2599
"Whirlwind Guide": http://www.falch.no/people/pepper/sgmltool/

Received on Thursday, 6 March 1997 03:30:52 UTC