Taxonomy, Link Relationships - where does it all fit?

This taxonomy/relationship stuff is extremely interesting but I have a
yearning for some structure, some layering of the concepts being discussed
to help me see the wood from the trees.

I think we are going around in (highly interesting) circles but circles
nevertheless owing to a lack of an agreed terminology base and an agreed
layering of highly slipper concepts like "syntax", "semantics", "behaviour",
"relationship" etc.

I have been trying to build a mental picture of what has been discussed in
recent days and have ended up with a 3 layered model (and some comments
about a possible level 4).

I present it here for comment, ridicule or a mixture of the two:-

Layers to the XML effort
========================
Level 0 : Syntax
----------------
Lexical structure of XML documents heavily based on SGML.
Concerned with tokenising/separating markup from data content.

Level 1 : Static Semantics
--------------------------
"Well-formed" docs have matching start/end-tags etc. The whole
doc forms a tree structure (okay then, a grove)

"Valid Docs" form "sentences" of the grammer defined in the DTD.

Level 2 : Application Semantics (or Dynamic Semantics)
------------------------------------------------------
Adding run-time behavior of one form or another to the abstract data
structures defined by level 1.

Examples:-
	Rendering docs on screen, paper etc.
	Interpting elements as hypertext links etc.
	Spiders, Agents and XML data processors of all kinds.


Now some opinions based on this layering and terminology:-

a)
The question of whether there should be pre-defined link types boils down to
whether link behaviour should be at level 1 (Static Semantic) or  level 2
(Dynamic Semantic) characteristic.

I see link relationships such as "Approved-By" , "Is an Amendement To" etc.
as a Level 1 characteristic and their behaviour as a Level 2 characteristic.

b)
XML certainly concerns itself with levels 0 and 1. So far, rendering is a
known area of (future) XML activity that occurs at level 2.

At Level 2, Link behaviour and rendering are inextricably linked. I see no
sensible way to deal with them other than discuss them together.

c)
We don't want to hard-wire application semantics but we do want to make it
easy to use XML "out of the box". Thus the desire to make Rendering
Application Semantics part of XML and to make Hypertext Application
Semantics part of XML.

We want a formal, unambiguous way of expressing Application Semantics that
does not force any particular implementation regime down anyones throats.
I.e. no particular programming language, no forced "you must do it this way".

d)
I think we should be careful to ensure that "browsing XML on the WEB" is
just one of the things you can do with XML. I can see mind-blowing
applications built around XML that do not involve browsing any XML at all
(except perhaps the "result" of some serious XML crunching.)

e)
Level 2 - Application Semantics is part of the XML effort which currently
encapsulates Rendering + Hypertext. The key is to somehow implement these
things at level 2 without limiting what *might* be done in the future -
either in terms of additions to XML standard Application Semantics or Killer
Applications developed by XML users.

Tentative Conclusion
=====================
We need a Level 3...

Level 3 - Application Semantic Specification Language
-----------------------------------------------------
A language for the formal expression of :-
	How to go about rendering this document
	How to interpret the meaning of an "ilink" element etc.

Naturally, the language should be general enough to allow currently
unconsidered application semantics to be formally defined.

Ideally, the language should be "executable" so that the application
semantics can be executed directly as well as cross-compiled.

Also ideally, developers should be free to view the language as a formal
expression of the application semantics and just use it as a guide for
implementing it in C, Java whatever.

Sounds like Scheme and DSSSL to me!!! Can we use Scheme/DSSSL to specify the
link resolution "algorithm" involved in clink, ilink etc. If so, doesn't
this give us a clean way of pre-defining link relationships without throwing
the baby out with the bath water?

Sean Mc Grath
digitome@iol.ie

Received on Saturday, 25 January 1997 11:33:59 UTC