Re:Can we be more concrete...

At 10:50 AM 12/31/96, Digitome Ltd. wrote:
>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.

I definitely agree. I think nothing that has been proposed will actually
make things complex. The problem is that we have to rationalize all of the
(slightly) divergent models of the participants -- and that is more complex
than the actual proposals.

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

So far we really have agreed on the 80% (I think):
   clinks. (ordinary links), stored at one endpoint pointing somewhere else.
   ilinks. Links separately stored from both endpoints
   Multi-way links (an extension of both sorts of link) for annotation and
knwoledge representation.
   Logical document part addressing. Now that we have structured XML
documents, we want to be able to use that structure as an addressing
mechanism.

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

I hope these things meet those criteria. To make that clear, we will have
to show examples of how to solve problems with the new constructs, but I am
sure that that is easy and will happen.

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

It's a _critical application_ I think, because of the (erroneous)
identification of HTML and Hypertext in the minds of the world at large.

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

In practice they are very simple -- it's jsut a way to base processing on
attribute values. The explanations to date have concentrated on explaining
how to use architectural forms to describe markup. But in the XML linking
spec, we will only have to describe how to set attributes to make links --
the application of a fixed set of AFs to an arbitrary document.

   This should be a lot easier to explain than the general case. AFs are
becoming a very productive method of DTD standardization, and we might as
well use them.

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

I think we are moving to curb the eventual concept space to a small number
of easily definable items. I think we can avoid use of Hytime terminology
except where it is the best choice, and must define our terms clearly and
independently of HyTime in any case.

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

I think we are converging on that subset, and will be able to settle on a
subset of (possibly simplified) HyTime terms for XML linking.

>3.2
>Users will never care how the pop-up list of hot-spots arrived onto
>there browser screen.

but XML authors will, and implementers will

>They will never care that an anchor is not an
>anchor until it is referenced by a link.

I have been using Tim's revised terminology, where an anchor is an element
introduced solely to be referenced. We should only care enough that we have
the words we need to write the definition.

> The will think an "anchor
>role" is a form of acrobatics performed by sailors:-)

Well, we could change the term to "jelly roll" for a tastier standard.

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

yes, I hope we introduce no more than we need to satisfy this need.

>These guys understand the concept of a tree,
>the notion of an address and the notion of an indirect address.

That's why I prefer the terms "parse tree" or "abstract syntax tree" to
"grove", "grove plan" and their friends.

Maybe we should be calling "locations", "addresses", and "queries", "pointers".

In practice, I think we will be OK as long as we don't have the terms
"locator", "location", "location address", "external location address
pointer", etc. all floating around with slightly different meanings.

> If this was done could we maintain a link (sorry)
>to the "correct" HyTime terminology and include it in an appendix?
 Or even a separate document, for those who need it.

   -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Tuesday, 31 December 1996 13:07:04 UTC