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