W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > January 1997

Re: Relationship types

From: len bullard <cbullard@hiwaay.net>
Date: Sun, 26 Jan 1997 16:24:58 -0600
Message-ID: <32EBD9B9.1E4B@hiwaay.net>
To: "David G. Durand" <dgd@cs.bu.edu>
CC: w3c-sgml-wg@www10.w3.org
David G. Durand wrote:
> At 4:48 PM 1/24/97, Len Bullard wrote:
> As a co-author of the committee draft of the TEI pointer syntax, I'll risk
> a few comments here.

Appreciated, of course.

> Of course yo can out anything you want in a CDATA field, but we need not
> define a method for link-semantics hacking any more than we need to have a
> Rainbow-DTD equivalent to make XML rendering plausible.

No, but the availability of the attribute is similar to the 87269 
attribute and will be used in non-interoperable ways just as it was 
in 87269.

> You mean a fixed element type? Heaven forfend. The TEI attribute value
> syntax should be adopted, _not_ element types.

Ok.  Would this be as an example of an XML linking architecture, 
or THE XML-linking architecture?

> >I'm still not sure how one would specify chained traversal
> >to prevent goto/label where not safe, but I've not had
> >the document for very long.  What I wanted in MID was a
> >sequence of locations one could point to using a nameloc
> >and implying that identifier order was strict, but I
> >was overruled on that one.  I thought it easier to
> >say, "here is a list of id/locations.  Traverse in
> >sequence".  So we used the chain element type and
> >containment instead of indirection.
> I don't know if I understand what you're aksing for. But if I do, I think
> you would just make a multi-ended link or a link group and leave it to the
> application or stylesheet to specify parallel or sequential display. There
> are no pre-wired rendering semantics anywhere in the TEI.


> >Regardless of how folks like it, scripts in declarative
> >markup are now a way of life and will not go away. 
> I refuse to recreate Hypercard in Java. You don't seem to be winning this
> argument to hard-wire presentation semantics, but if you do, I hope I won't
> be the only one arguing that XML linking is best ignored. 

Hardwired semantics are a fact of life in many products.  Where they 
are used in XML, they will be used to make a particular application 
more efficient in its own environment.  That will happen with the 
usual well-understood tradeoffs.  It isn't an argument I have to win;
it is a application someone will write.  We just have to disagree 
on the utility of it.  I do not see any XML requirements to support 
it natively.  Again, I offered the MID simply as an example of a way 
to do relationship linking.

No one wins an argument on this list anyway.  We discourse, the 
editors propose, the ERB disposes.  We move on.   

> You can embed
> scripts in declarative markup to your bady-designed system's, rewire it
> twice-a-decade,  heart's content, but there is no reason for XML to
> encourage data obsolescence for links, when it is trying to save people
> from it in their documents.

You are absolutely right.  But common practice is there as precedent 
and our differences of opinion about this issue are something the market 
works out in practice.
> You're right though, there are no new arguments in this debate. Let's see
> what the editors propose.

Yes.  I think I see the shape of that and have no objections.
>     But let's make sure my posiiton is completely clear. I _do_ agree with
> the need for an easy start-up for linking "out of the box". However, I
> think that that is best handled by well-publicized beginner DTD/stylesheet
> pairs.

> >In any event, a normative list is not needed.  Examples
> >will do just fine.
>    That's good. Since I've seen no support for a normative list of
> linktypes, we probably don't need to mention this again.


Received on Sunday, 26 January 1997 17:25:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:07 UTC