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

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

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


Regards,
    Terry Allen    Fujitsu Software Corp.    tallen@fsc.fujitsu.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

Received on Wednesday, 22 January 1997 19:30:02 UTC