Re:Can we be more concrete...

For the record, I am an ordinary software developer. I consider myself
absolutely average as an exponent of that art. I am anxious to do my
bit to try and ensure that the simplicity and clarity of XML is
carried on into the realms of hypertext, rendering and beyond.

If I irk anyone with my ignorance in what follows, I apologise in advance.
However, in my defense I will say that I believe I am representative
of the "Humble Software Developer" who needs to be sold on XML. If I
have grave misunderstandings, I am not alone.  Anyway, here goes:-

1. The simple things should be simple

It will cut no ice with the software development community if XML
Hypertext allows links from arbitrary tachyons to a range of faces on
a hypercube *IF* this is at the expense of making "link this word to
that file" an intellectual safari.

There are many exceptional hypertext exponents on this list who know 
from experience what sorts of Hypertext functionality is sorely
missing from the Web. The sort of things that will make the eyes of
current Web masters glaze over. What are these things?  Is there an
80/20 rule applicable to Hypertext?  20% of hypertext concepts used
80% of the time?

Should we not start by saying "here are the things
that we *know* people are crying out for.  Here are the things that
will capture the imagination of Web implentors and users alike. Here
are the things that will sell Web masters on XML". Can we isolate
these things and concentrate on making them "no-brainers" to implement?

2. Hypertext as an XML application?

Is Hypertext an application of XML or a raison d'etre of XML? I feel
it is an application - one of myriads that can be envisaged. I think
hypertext semantics/functionality should be *outside* the XML
documents themselves for this reason. I am concerned about
the architectural form approach because:-

.	Architectural Forms is an intellectual safari
.	Anything that can be expressed in an architectural form
	can also be described as an XML document. (I think!)

From a developers' perspective the idea of using the XML parser to
process XML documents that "talk about" other XML documents in various
ways sounds clean and appealing. It whould make it simple to do the 
simple things.

3. Terminology
HyTime supports such a rich set of ways to link things to other
things that the seemingly straightforward terms like "anchor",
"link" become very difficult to tie down as we have seen in the
recent discussion.

3.1
If a sub-set of HyTime functionality is decided upon does
the terminology problem get any easier?

3.2
Users will never care how the pop-up list of hot-spots arrived onto
there browser screen. They will never care that an anchor is not an
anchor until it is referenced by a link. The will think an "anchor
role" is a form of acrobatics performed by sailors:-)

The people who need to be clear on the terminology are the 
implementors, the programmers, the techies out there that we want to
reach with XML (me!). These guys understand the concept of a tree,
the notion of an address and the notion of an indirect address. They
understand associative arrays, dynamic binding, namespaces, pointers
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?

Sean Mc Grath
digitome@iol.ie

Received on Tuesday, 31 December 1996 10:11:20 UTC