Re: ERB decisions on the LINKTYPE proposal

Sumary. last I will say on this, my major point is that my primary
objection to LINK in the XML context (that it doesn't solve our problem)
has not yet been addressed.

At 9:27 AM +0100 3/6/97, Steve Pepper wrote:
>At 19:30 04.03.97 +0100, David Durand wrote:
>>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.

I didn't see that admission (and am surprised if he made it), but in any
case, since I am claiming it is the major argument against LINK, I think
you must concede the case if you can't respond to it. However, I will
restate it in as concrete a form as I can manage, given that the basis for
the argument (LINK itself) is so much more convoluted than it has to be.

I ma pointing out a conceptual problem, not an implementation problem. It's
one more hash table in an implementation -- but conceptually it's very
difficult because we have chosen to use ELEMENT attributes to detect links.
Any element can be a link if it has the right attributes, even without a
DTD. We want the multiple attlists only so that people who want not to
repeat a mass of specific attributes throughout their instance will have a
way to deafault their values.

This problem, is not solved by LINK as defined in 8879. We could steal the
syntax, but would either have to change the meaning from that presecribed
by 8879, or we would have to add a new notion of 2 kinds of attributes --
one specified by a PROCSPEC, and one specified on the element, and give
rules for deciding which kind can make an element into a link. I think that
this will make the standard more bloated, and more confusing.

If we make LINK the only way to associate linking semantics with XML
elements, we lose the ability to use XML-LINK attributes freely in the
instance, and make the LPD  a requirement for any document that uses
hypertext links. This means that LPD-free instances could not use hyertext
linking. A loss, in my view.

If we base everything on _element_ attributes, people can type a lot of
xml-link attributes, or use detached ATTLISTs if they want to save typing,
or if their tool wants to save bytes.

The HTML-in-XML DTD will of course include the attributes already, and not
require any special work from the author.

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

If you're trying to plug default values into a namespace, inability to
create "collisions" is a problem, not a feature.

>>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?

And how does a dumb browser know which to do?

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

No, but there's little reason to throw a big bag of marbles into a
roller-skating rink, either. That is, why create extra opportunities to
screw things up, when you get no decisive benefit from it.

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

Well, I hate the syntax too (though the restricted form is obviously much
better), but given that the semantics are wrong, it's pointless to
concentrate on syntax (where it is hard to make engineering arguments in
any case).

>>>* 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?

Well, I can't find the message, so it must have been someone else. Whoever
it was pointed out that it was not just 1 production but several
productions and yet more terminal symbols, in a language whose spec is
already a little longer than we wanted...

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

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

This motivation was not in effect at the time Exoterica took that decision.
And I think that citing authorities like Lynne Price is not a feeble move.
Her knowledge of the standard document, and commitment to SGML are beyond
questioning, in my opinion, and I remember her telling me that she simply
didn't believe the _standard's text_ provided sufficient information to
create a sensible implementation. Lynne would neither extend or relax the
standard one iota, so that I take her opinion quite seriously. But you
don't have to if you don't want to.



  -- David

_________________________________________
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 Thursday, 6 March 1997 13:17:30 UTC