Re: Relationship Taxonomy Questions
Executive summary: Plain Language still needed
Eliot responds in good humor:
| You're right, I didn't. I think by primitives we mean either discrete
| building blocks that are combined to form complete wholes (e.g. "style
| primitives" such as font size, color, family, slant, etc.) or, in the case
| of types, fundamental taxonomic types or classifications ("archetypes?")
| from which more specific types can be derived. We discussed the
| possibility of "relationship primitives" that would be combined to create
| new types, but Steve D. convinced us it was not tractable (and quite
| possibly not useful), at least in this forum.
Without examples, this isn't much help.
| >| 1. Is it necessary or useful for XML to define some finite set of
| >| well-defined relationship types or primitives?
| >Assuming you mean something straightforward, no. Defining
| >the semantics of relationships is not for a metalanguage.
| You always have to define some level of semantics--even SGML defines the
| semantics of "markup" and "data", "element" and "attribute". However, many
Which are not relationships. I said "semantics of relationships."
| of us feel XML needs to also provide at least a little bit of semantics in
| the form of an architecture for the representation of very common
| constructs, possibly including some sort of "starter set" document type
| that people can use immediately to create documents without having to also
| engineer style sheets and so on. Defining such a starter set doesn't
| preclude the use of any other document types, it simply makes the cost of
| entry lower for those for whom the starter set is sufficient.
Certainly XML should not define XML DTDs. I don't know what you
mean by "an architecture for the representation of very common
| >| Our presumption, as yet unproved, is that the interoperation of XML
| >| documents within some general purview (e.g., the Web, as opposed to
| >| domain-specific purviews, such as a particular intranet) requires some
| >| basic set of link types whose meaning is well defined and understood. This
| >What's a link type as opposed to behavioral and relationship primitives?
| >What is the "meaning" of a "link type"? For that matter, what is a
| >"link type"? Please give simple examples.
| A link type, as indicated above, is a relationship type (at least in this
| proposed model of link representation). The two are synonymous, because
| links represent relationships. The meaning of a type is the description of
| the relationship.
You never defined "relationship type," either. But see next.
| If I have a link type of "foo", you have no idea what it means. But if I
| say a foo relationship associates a pet to its master in order to express
| ownership of the pet by the master, then you know that foo means "owned by"
| (or "owns" or "ownership"--however you prefer to state these things). If I
| then say I have another relationship "bar" that associates pets with their
| trainers, you know that a "bar" relationship means "trained by". I have
| defined two relationship types ("foo" and "bar") and defined their
| semantics ("ownership" and "instruction").
So a relationship type is a relationship ("bar" is both a relationship
and a relationship type). Then everything you write comes down to
the assertion that links somehow represent relationships. I infer
that you also want to key application behavior off the labels for
relationships that you attach to links. XML 1.0 doesn't forbid you
to do that, but I certainly don't want that to be required.
And specifying a list of relationships is out of scope for XML,
although it might be meritorious activity on its own. I at least
don't want to tie XML to any particular set of relationship labels.
[long example of a relationship Eliot is surely not proposing
to be standardized deleted]
| Note that all of this discussion has *nothing* to do with behavior. When I
| actually create a document relating pets to owners, there are any number of
| behaviors I might want associate with the different types and roles,
| depending on my mood, the user of the information, etc. But the behaviors
| don't change the nature of the relationships described.
And I might want to do the reverse, assigning different behaviors
to occurrences of the same relationship labels. Aside from that,
these labels are really elements and attributes, and I can assign
behavior directly to them if I want. You seem to be assuming one
architecture among many possible ones.
| >| We take it as a given that the set of possible relationship types is
| >| unbounded.
| >So obviously no subset of them will be satisfactory, and we need a
| >general way to refer to them, whatever they are.
| No classification scheme can ever be complete. We're only wondering if
| it's necessary or useful to build the beginnings of one for link types.
| [The presentation I enjoyed most at last year's Hypertext conference was
| the closing keynote by the woman who described her research into the
| sociology of classification. The basic messages were "every useful scheme
| needs an 'other'" and "every classification exercise has political and
| social implications and constraints". Since SGML (and by extension, at
| least in my world, hyperlinking) are mostly about defining classification
| schemes, I found this presentation very enlightening. I recommend hunting
| up the proceedings and reading it. I'd provide a citation if I knew where
| my proceedings were.]
I think that speaks for itself. This is definitely out of scope for
| >Cart before horse. The syntax serves to enable behavior; behavior should
| >be established first.
| We (the ERB) don't agree. Our feeling is that behavior and syntax are
| independent. Because many applications of XML will need the semantics but
| will provide their own behavior specification mechanisms, we feel that
| doing semantics first is the proper order.
? I need to be able to specify the behaviors that Len's MID example
did (and did quite independently from its specification of relationships):
traversal ( gosub | spawn | goto )
I need to know those behaviors will work interoperably, and I cannot
rely on applications that "provide their own behavior specification".
If the ERB thinks that's going to work, I ask it to reconsider. And
I need whatever syntax is required to support specification of
those behaviors (perhaps none at all). I can already specify
relationship labels if I wish.
| For example, given an XML-defined way to describe link semantics, I can
Now what are "link semantics"?
| figure out to translate that into HyTime terms and provide the resulting
| documents to Panorama, HyBrowse, and DynaText, all of which provide their
| own mechanisms for defining behavior. Therefore, XML's definition of
| behavior is largely irrelevant to any use I might put XML to in the near
| term, but link types are not.
? Given whatever way XML or XML users describe links, you will be able
to translate it into whatever you want.
| >| In the SGML model, behavior can be considered an aspect of "style" or
| >| presentation and may be defined explicitly through "style sheets" or
| >| "processing specifications" or may be embedded into a particular
| >| browser or processor (e.g., HTML browsers pre CSS). In this broad
| >| definition of the term style, mechanisms such as scripts, controls,
| >| and plug-ins could all be considered aspects of style specification.
| >Or may be specified in a DTD or by labelling with well known semantics.
| >This is not a real useful definition of behavior. "Generally regarded
| >as poor practice" is your view, and you should label it as such.
| >| At this point we are assuming that behavior will be specified both in
| >| some normative way in an XML specification and, at user option, through
| >| some as-yet-undetermined behavior specification system or systems (e.g.
| >| "link style sheet").
| >Eh? the user gets to change the behavior of the links in the document I
| >sent him? That's a new one. Though perhaps your overbroad definition
| >of behavior renders the issue moot.
| The only way you can *ever* ensure a particular behavior for a document is
| to render it through a closed system. As XML is designed specifically to
The user cannot change the semantics of an HTTP URL, nor can he change
the semantics of HTML's A element. If XML specifies
traversal ( gosub | spawn | goto )
and that XML apps have to respect those semantics to be conformant,
the user will not be able to change the behavior of my document
in an XML app.
| enable the networked interchange of documents, any energy spent worrying
| about users changing behavior of presented documents is wasted. If you
| want "my way or nothing", use Acrobat.
Or Netscape, or Explorer, or Spyglass, etc.
[ ... ]
| >| semantic
| >| The "meaning" associated with a type. The term "semantic" is dangerous
| >| because it is overloaded and can mean different things in different
| >| contexts. In this discussion, we are trying to clearly differentiate
| >| meaning, which is abstract, from behavior, which is concrete. In
| >| there is a one-to-one relationship between a type and its semantic, but
| >a what type? How did you arrive at this generality?
| It's the freakin' definition of type: a label for a set of semantics. Or
| would you prefer a Dadaist approach to type definition?
Oh, then "in general" is just useless verbiage. I see.
Again, I invite to state plainly what it is you're asking for. I
suggest that it should take no more than 20 lines, plus your list
of your favorite relationships.
Terry Allen Fujitsu Software Corp. email@example.com
"In going on with these experiments, how many pretty systems do we build,
which we soon find outselves obliged to destroy?" - Benjamin Franklin
A Davenport Group Sponsor: http://www.ora.com/davenport/index.html