Re: Can we be more concrete?

At 03:47 PM 12/29/96 -0800, Tim Bray wrote:

>To make it concrete (and I apologize to those who are reading
>this particular example for the second time, I sent it to someone, but
>not *I think* the SGML-WG):  At SGML'96 this outfit had a multimedia
>authoring system called "Nereus".  They had some circuit board photos 
>and you could click on the parts and a little menu would pop up saying
>
> Locate Part
> Show Measurements
> Describe Part

What do we need to build a system that can do this (or rather, what data do
we need in the documents that would drive this system)?:

1. A way to address regions of a graphic: I'll use a modified
   client-side image map syntax, just to pick something.
2. A way to represent the data to be related to the graphic: XML documents,
   natch--I leave the definition of these documents to whoever wants to
   figure out to make the PCIS (Pinnacles) DTD XML conforming (which it 
   might be out of the box) [PCIS is the semiconductor interchange DTD].
3. A way to represent the relations between the regions of the graphic
   and the data: HyTime-style hyperlinks, of course. [I say HyTime-style
   because it doesn't matter whether they actually conform to HyTime or
   not for the purposes of this discussion, but it happens that my 
   design does conform].

Assuming that everything in the document is an "anchor" as we've defined it
for XML, i.e., has an ID by which it can be addressed and further assuming
that the URL notation "#name" is interpreted as an ID reference for XML,
all I need to do is define the hyperlinks themselves:

<!DOCTYPE CircuitRelations [
 <!-- Circuit relationships document. Normally one per circuit -->
 <!ELEMENT CircuitRelations (Title, ImageMap, PartDescs)
 >
 <!ELEMENT Title            (#PCDATA) >
 <!ELEMENT PartDescs        (PartDesc+) >
 <!ELEMENT PartDesc         EMPTY >
 <!ATTLIST PartDesc    
           graphic          IDREF #REQUIRED
           description      CDATA #IMPLIED 
           characteristics  CDATA #IMPLIED
           -xml-anchroles   CDATA #FIXED "description graphic characteristics"
 >
 <!-- "Characteristics" is the semiconductor term for what I think 
      Tim means by "measurements". A real application would probably
      be more precise in precisely which characteristics are 
      linked to than this example is. -->
 <!NOTATION ImageMap PUBLIC "-//DRMACRO//NOTATION My Image Map//EN" >
 <!ELEMENT ImageMap         (Area+) >
 <!ATTLIST ImageMap
 >
 <!ELEMENT Area             (#PCDATA) >
 <!-- Content of area is displayable label for the area -->
 <!ATTLIST Area
           ID        ID     #REQUIRED
           coords    CDATA  #REQUIRED
           notation (imagemap) #FIXED "imagemap"
 >
 <!-- Value of coords is list of x/y pairs defining vertices of
      closed polygon.  Last pair connects to first pair. -->
]>
<CircuitRelations>
<title>XYZ Framizitzer Cicuit</title>
<ImageMap>
 <area id=area-1>A bunch of transistors</area>
 <area id=area-2>A bunch of nand gates</area>
 <area id=area-3>Cache ROM</area>
</ImageMap>
<PartDescs>
<PartDesc graphic=area-1
          description="http://www.ti.com/datasheets/XYZ/framcir.xml#boftran"
          characteristics="http://www.ti.com/datasheets/XYZ/framcir.xml#char1"
>
<PartDesc graphic=area-2
          description="http://www.ti.com/datasheets/XYZ/framcir.xml#bofnand"
          characteristics="http://www.ti.com/datasheets/XYZ/framcir.xml#char2"
>
<PartDesc graphic=area-3
          description="http://www.ti.com/datasheets/XYZ/framcir.xml#cacherom"
          characteristics="http://www.ti.com/datasheets/XYZ/framcir.xml#char3"
>
</PartDescs>
</CircuitRelations>

Now I've related parts of the graphics (addressed by the Area elements) to
the descriptions of those parts and to the characteristics of those parts.
Nothing very hard here.  HyTime is never mentioned, groves are never
mentioned.  The addressing methods should be familiar to every Webhead.
The only thing I've added is declaring the image map as a notation so my
processor can distinguish it from all the other ways I might do the same
thing.

The behavior of these links would be defined by the presenting application,
either built into its understanding of the semantics, or defined through a
separate style spec.  A tool like HyBrowse will provide some default
behaviors and can be modified via style.  At a minimum, from any link end,
I'd expect to be given a list of the other link ends, distinguished by link
type and anchor role (if not by other metadata as well).  

I don't see how it could get much simpler than this.  Note that the image
map could be in a separate document--I showed it in the same document for
simplicity.  Presumably in a real application like this, the image map
would be bound to the image and not replicated.

There are other HyTime-conforming ways you could do this, but the above is
my initial guess at the best approach, both in terms of simplicity of
execution and completeness of semantic description.

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 Sunday, 29 December 1996 22:44:51 UTC