Re: Taxonomy, Link Relationships - where does it all fit?

Digitome Ltd. wrote:

> 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?

The only language the charter mentions is DSSSL.  The baby and the 
bathwater parted company there.  Nothing prevents the XML 
developer from ignoring this.  Many will, some will use the 
examples "out of the box".

We aren't churning in circles.  There are and always have been 
different ways to express hyperlinks (static/data object or 
dynamic/data structure) for years.  That's not a problem 
as much as a fact of the history of hypermedia.  Application 
languages settle the issue at implementation.  A meta-language 
is problematic in that the application (in SGML terms) is 
in expressed by the DTD, which we are told, should have 
no rendering information (open to debate depending on what 
religion you practice in SGML).  The reality is that many 
systems do insist on having such information in the 
application language and in fact, they have been well accepted
and sucessful.

HyTime attempts to bridge this by the concept of architectural 
forms which just *happen* to look like DTD fragments.  The 
concept of groves is there to tighten up the problems with 
the original ESIS which did not do the job.  It is a good 
concept based on a sound approach to parsing output.  TEI 
bridges the gap by providing not arch forms, but actual 
element types (e.g, xptr) and a set of attributes for 
location (e.g, grep like patterns, dataloc-types, treeloc-types etc.).

Both HyTime and TEI seem to be the same thing with some small 
variations in naming (e.g, reftype | targtype).  TEI extended 
pointers are a sensible subset of HyTime.  The are in your terms, 
static definitions, but their operations are defined axiomatically 
(i.e, in their documentation).

Insofar as a static approach goes, this is all good.
Avoiding dynamic definitions has the problem that no state 
definitions are given such as application languages like the 
MID provide for.  It can be said that state management is 
an issue of the application language and whatever implementation 
language or framework is chosen by the application developer.
However, without it, portable definitions can be created, 
but not true interoperable ones.

If this is the case, then there may be no need for DSSSL 
in XML.  IOW, stop with the static definitions and let 
the market choose the implementation language.  Should the XML
working group choose to consider the charter the limit 
of the working group's focus, then it will be best if the 
implementation/rendering be a non-normative set of examples.
That provides the ultimate flexibility and guidance, and 
enables conforming XML applications without the need to
implement DSSSL.  Using scheme/lisp as a Bachus-Naur form 
is useful, but is similar to the use of the arch form/DTD 
fragment.  It is hard to convince people they don't *have* 
to do it that way, so many programmers unwilling to do it 
that way toss the whole spec out and move on.

Len Bullard
Lockheed Martin

Received on Saturday, 25 January 1997 12:13:05 UTC