Re:Can we be more concrete...

At 03:50 PM 12/31/96 +0000, Digitome Ltd. wrote:

>etc.  Should we not be building on this existing terminology base
>rather than invent a new one? This, after all, is the terminology of
>the target market. If this was done could we maintain a link (sorry)
>to the "correct" HyTime terminology and include it in an appendix?

As I said in an earlier post, even if the final XML design is HyTime
conforming, it's not necessary to expose that in the base spec--thus
there's no direct requirement to use HyTime terminology in the spec.  It
will be necessary to provide the mapping from XML terms to HyTime terms at
some point, either as an appendix to the spec or as a separate TR.

I say this because I recognize several realities that constrain the direct
exposure of HyTime in the XML linking spec:

1. There is, for whatever reason, significant hostility to HyTime in general.
   Why invite trouble?  HyTime, as a standard, is a somewhat different
   animal from SGML, in that HyTime is designed, in part, to be retrofitted
   to existing document types and applications: it defines semantics more than
   syntax, therefore, there's less urgency in building in HyTime from the
start
   (although I still think that's a good thing--but then I would).

2. HyTime, is, by the nature of its scope and generality, complex and
   somewhat difficult to understand (although I hope we've improved on 
   that with the TC).  Because what XML needs is relatively simple compared
   to the totality of what HyTime (or any other industrial-strength
   hypertext scheme) can do, there's no reason to unduly burden the XML
   Link spec with complexities it doesn't need.  One of the points of
   XML is to hide the complexities of the architectures from which it
   is derived until you're ready to move beyond XML.

   Note that we, as designers of the spec, will have to expose to 
   ourselves some of these complexities so that we can come to 
   clear agreement on the simplifications the final spec embodies.
   In other words, we have to know how the simplicity and constraints
   of XML Link relate to the more general features and concepts of
   the specs from which they're derived (whether that's HyTime, TEI,
   or whatever).

   It's a cliche', but a true one, that only experts can write good
   basic texts.  Thus, in the process of applying our collective
   expertise (which is pretty vast) to the problem of creating a
   basic text for XML Link, we'll have to chew on many expert-level
   issues, in part to be sure of those we can avoid in the spec.

3. The terminology of hypermedia is, in general, murky, and HyTime 
   doesn't necessarily help--many of the common terms are overloaded
   and not necessarily intuitive to the uniformed observer.  Therefore,
   we should give greater weight to usability of the spec than to
   terminological conformance to one particular standard.
   
As an aside, there's no point in trying to defend the terminology used in
the HyTime standard: it's there and that's that, for good or ill.  But I
think it's important to remember that HyTime was developed over a period of
years during which many of the important concepts and terms of hypertext
were being developed, so that, at the beginning, there were not always
clear precedents for the use of a particular term.  In some cases, the
choices were arbitrary, in others, they made sense within the HyTime
system.  In some cases they were chosen out of ignorance of alternatives.
This is the way all standards are developed--it's unavoidable given human
nature and human failings.

Cheers,

E.
--
W. Eliot Kimber (eliot@isogen.com) 
Senior SGML Consulting Engineer, Highland Consulting
2200 North Lamar Street, Suite 230, Dallas, Texas 75202
+1-214-953-0004 +1-214-953-3152 fax
http://www.isogen.com (work) http://www.drmacro.com (home)
"Rats in the morning, rats in the afternoon...if they don't go away, I'll be
re-educated soon..."                 --Austin Lounge Lizards, "1984 Blues"

Received on Tuesday, 31 December 1996 11:08:03 UTC