ERB terminology votes

The ERB met Sat. Feb. 15th.  Present: Bosak, Bray, DeRose, Magliery,
Maler, Paoli, Sperberg-McQueen.  All decisions were unanimous.

We spent most of the time on the issue of terminology detail.  
Although this was not articulated formally, some underlying design
principles seem to have guided us:

 1. We should re-use Web terminology where appropriate (thanks to
    Dan for this input)
 2. We should not be afraid of lengthier English compound constructions
    as opposed to single words, when this makes things easier to
    understand and explain (thanks to Liora)
 3. We should distinguish clearly between terms for the 
    underlying Platonic concepts and those for the syntactic
    constructs (thanks to Henry)

We had discovered that, even at this late date, there was still room for 
confusion as to which bits were which; so Steve and I, inspired by 
Henry, cooked up a simple picture that was very helpful:

<BOOK><A NAME="foo" HREF="http://x.com/y/z.html#SEC1">Click here</A></BOOK>
|------------------------------p0-----------------------------------------|
      |------------------------p1----------------------------------|
                    |----------p2-------------------|
                          |----p3------------------|
                          |----p4-------------| |p5|

<BOOK><SEC ID="SEC1">Thank you for clicking to get here.</SEC></BOOK>
|------------------------------q0-----------------------------------|
      |------------------------q1----------------------------|


1. The relationship which the "<A" element asserts the existence of is 
   called a "link".  
   
   There is an interesting ontological debate as to whether the 
   link is in fact the assertion, or whether the link already existed and 
   the linking machinery merely *describes* it, but it is probably not 
   necessary to resolve this for the purposes of the spec.   I will 
   cheerfully argue this point with anyone as long as they keep buying
   the necessary beer.  WWW theory, as pointed out by Dan Connolly, is 
   explicit that the link *is* the assertion.

2. An XML or SGML element (example: p1) which serves as the 
   syntactic expression of a link is called a "linking element".

3. A participant in a link relationship (example: q1) is called a 
   "resource".  Our definition will be very similar to the official 
   WWW definition, found in
      http://www.w3.org/pub/WWW/Architecture/Terms
   which everyone on this list should go and read.  That definition is:

    an addressable unit of information or service in the Web. Examples 
    include files, images, documents, programs, query results, etc.

   In our case we should not limit it to "in the Web".  Note that a
   resource could include the results of an SQL query, a temporally
   limited section of a video clip, or the invocation of a script that
   flushes a toilet in Tuktoyaktuk.

   There is an interesting debate, in the case of the example, as to 
   whether one or two resources are involved.  Clearly, "q1" is a 
   resource.  If there another resource, it is *probably* the linking 
   element itself, "p1".  It is clear that in some cases (independent
   links or out-of-line links or whatever), a linking element need
   not be a resource.  Unlike the ontological debate mentioned above, 
   we are going to have to decide this one to get a clean spec.

4. A string used to specify a resource (example: p3) is called a 
   "locator".  It might be a name or an address or a query expression; 
   one way or another it is undeniably used to locate the resource.

5. An attribute containing a locator (example: p2), is called a
   "locator attribute".  Should we end up, in the case of multi-ended
   links, using subelements to hold locators, they would be called
   "locator elements".

Note that a few items that are labeled in the picture do not appear in
this discussion.  They appear because our discussion revealed that we may
not be finished with the terminology battle; there may be some more 
concepts that are worthwhile nailing down.  My next message will present 
these issues for further discussion.

Cheers, Tim Bray
tbray@textuality.com http://www.textuality.com/ +1-604-708-9592

Received on Monday, 17 February 1997 03:20:32 UTC