Re: Relationship Taxonomy Questions (3 CCs deleted)
At 7:33 AM 1/23/97, Terry Allen wrote:
>I need to be sure it happens, and mapping behavior to some label
>on a element is only one way to do it. There is more than one SGML
>way to skin a cat.
For such a guarantee, you must go outside the XML domain to a fixed
browser. XML will have stlyesheets, so a user will be able to make your
warning _INVISIBLE_. This is part of what we want for our markup, because
markup is about _decoupling behavior_. (And user stylesheets are not just
trivia, this is how we can support blind users for instance -- they
_always_ use a substitute style sheet).
>And in response to Jon's clear statement, I certainly don't want to
>forbid him from taking this approach, and there is nothing in XML 1.0
>to prevent him from using it, but I don't want to be *required* to use it.
Then implement your own acrobat-equibvalent (using XML-syntax if you like).
Jon's statement is _exactly_ what we should be doing. We describe document
element types instead of formatting behavior, and in exactly the same way
we should describe document relationship types, not behavior. And don't
throw out the reasonable-seeming, but irrelevant, objection that the notion
of link-type is not well-defined. If you think link-types are abstract, try
to give a formal definition of what an element type actually is. No one
knows, but that doesn't mean that giving authors and users a way to label
_what it means to them_ is not useful.
>Put another way, I need to be able to bind link behavior to my document,
>and I want to be able to describe relationships that do not map
Then you have more than one kind of realtionship: In SGML if you want some
paragraphs to format differently, you have two choices:
1. If the formatting is related to the structure, write a stylesheet
that algorithmically decides how to format, based on that structure. (E.g.
first para of a chapter has no indent)
2. If the structure _cannot_ enable such a stylesheet, ipso-facto, you
have different strucures and hence a new element type.
Now this is baby DTD design, and would also be baby link-design if the
world wasn't hell-bent on repeating every mistake in computing every single
time anything new happens. Take the example of print-formatting of links.
Behavioral specs are useless there (all of the MID types are at least, as
far as I can tell). They are useless not because there isn't _some_
possible mapping into the primitives of print presentation, but because you
can't determine from the behavior of a browser, what the behavior of a
text-formatter should be.
>| And when they are clicked on they are downloaded, but not
>If part of my document's text is included through a link, *and the
>document is being displayed*, the included text must be displayed when
>downloaded so as to display the full text as I intended it, complete
>with safety warnings, etc. Else I can't rely on my data format to
>convey my content, and the XML format is useless for practical
>purposes, however interesting it may be for hypertext theory.
This is the same argument that is made for TROFF over SGML. And it's just
as fundamentally bogus, I'm afraid. Indirection does not make anything
impossible or useless.
>| In fact a web walker is a "user agent" that *does* implement
>| link behaviour significantly different than a browser.
>It doesn't display any link behavior or the underlying document to
>the user, however.
It needs to understand that the links are different.
A print formatter does all those things, and has the same problems under a
behavioral implementation. Even behaviors such as transclusion that seem to
map nicely, may have special cases depending on the semantics of the
original link creation.
>They have to distinguish beween traversal and inclusion links, else
>they can't represent the document properly, even in outline. Note
>that we don't have text inclusion in HTML.
For instance transclusion of other people's work, may need to be rendered
as a citation in some contexts. This could be determined (or at least
enabled) by link types, but never by a behavioral spec.
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 \__________________________