Re: Relationship Taxonomy Questions
At 9:52 PM 1/23/97, len bullard wrote:
>David G. Durand wrote:
>> >Once you try to specify a class relationship (supertypes, subtypes)
>> >and expect inheritance and interoperation, you have to specify
>> >standard operations.
>> Why? What are the standard operations on Mammals and elephants required to
>> support the statement "An elephant is a mammal".
>a == b.
You help make my point, inadvertently. == is a relationship between
instances, defined logically by as being a transitive, symmetric, reflexive
relation. My point is that our document instances and parts will have many
complex identity, part-whole, has-attribute, is-a, etc. relationships. But
these are all _declarative_. They are _facts about instances_. eg. a == b
is an assertion about a and b.
The operations we want to define on these objects are how to bind a set of
methods onto the abstrct relationships defined by our data model. In an
implementation these would be "get" methods (the issue of "set" methods
will be a thorny one in stylesheet design, I guess).
And that's because a meta-language (of this peculiar sort) is about
describing a structure intended to be the object of an arbitrary
computation, not about describing the computations themselves.
>> >However, if you expect these XML processors to interoperate,
>> >the easiest approach is to use some "pernicious" concepts
>> >from real world systems. Your sponsors are already doing that.
>> Sure. Why don't we use raw TeX for markup too? It does better text layout
>> than any of these crappy browsers. The prevelance of bad solutions does not
>> make them less bad.
>Could be. It's a nice safe academic position. Hell on someone selling
>systems though, and hell on those who have to use them. HTML won
>because it was easy. Some folks have made that point to me too
>many times to forget it.
As I said, I refuse to take academic as an insult. Generic markup was an
academic position once (based on real issues). Those same issues have
already bitten some of us in managing link types already. You may like
changing attributes on all your link instances, but some people used to
like changing all their TROFF macros for a new typesetting device.
>> XML is about data representation. XML stylesheets are
>> about coupling operations semantics to representations.
>XML is about a standard syntax for enabling designers to write
>quick and dirty application languages and parsers. XML stylesheets do
>not exist, nor do they have to. You want them to, and you want
>them to be something you like, but I am not bound by that nor is XML.
>At least, not yet.
Perhaps this is a good point to stop. I don't have any objection to using
XML for that, but I don't think many people here think that is the purpose
of this excercise. The easiest standard syntax for quick and dirty is LISP
syntax, or maybe (for even simpler problems) TCL syntax (single lines of
The XML charter has mentioned styleshets from day one. You may not want to
use them, but that is not a constraint on those of us who accept the intent
of the charter.
>> XML linking should also be about representation. This is not deep, just
>> tacking labels on, and co-indexing executable functions to the labels later
>> on. It's a good idea for links for the same reason that it is a good idea
>> for texts.
>Goto(label). Considered pretty weak even in C.
No, I was talking about naming elements. That's the core of the semantics
of SGML. providing a facility to name link types is all we need to do here,
just as a facility to name elements was all we needed to do in core XML.
It is weak, but it is also powerful, since you can idirect to _any_
process, as opposed to being stuck with one analysis of what you want to
>> SGML/XML markup is just about ataching labels, and letting the processor
>> take care of itself. This does not always make life easier in the short
>> run. I can get better results quickly with a word-processor than an SGML
So, if we are using XML and generic markup instead of RTF (even though it
is in fact _more work_ in the short run), there might just be a reason.
That same reason happens to apply to link behavior just as well as to
>> It should be no surprise if linking were to show similar phenomena. I
>> think that a XML version of HTML (with example stylesheets to make it work)
>> will provide the simple semantics for simple needs.
>No doubt about it. The trick will be to get a user who never had
>to write a stylesheet before to do <font></> to do it now: for the
We have already signed up for that task by using XML. If they've got to use
a stylesheet for font, they might as well do it for everything. We might as
well be hanged for a sheep as a lamb!
>> In linking as with document structure, XML will have much more under
>> the hood for the long term.
>Two blank eyes stare back from under the hood of the robe of
>academic theory. They see... a 1970 database where a millenium
>object-oriented system should be. The poverty...ahh, the poverty.
Give me a break. You're the one who is proposing that we settle on a list
of hypertext behaviors, rather than leaving behavior open.
The crazed hacker says takes a slurp of coke, and says
"Hey it's real easy, see. The link behavior is just in this little macro.
we can make goto do whatever we want."
His fingers tremble as he pages through the listing until he finds the
right spot. Then he stops, and listens, and says:
"No, no, we can't make those links different now. They're goto links. If
you wanted footnotes to be different from cross-references you should have
told me before we sent that data to be keyboarded. If you want to do that,
we're going to have to look at every goto link in the whole 5 GB to see
which are footnotes and which are xrefs"
Ah, the horror... the horror...
I am not a number. I am an undefined character.
David Durand email@example.com \ david@dynamicDiagrams.com
Boston University Computer Science \ Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams
MAPA: mapping for the WWW \__________________________