Re: Can we be more concrete?
Subject: Re: Can we be more concrete?
From: "W. Eliot Kimber" <email@example.com>
Date: Sun, 29 Dec 1996 20:42:51 -0900
From firstname.lastname@example.org Sun Dec 29 22: 44:51 1996
X-Hobby: low-tide clam sexing
X-Mailer: Windows Eudora Pro Version 3.0 (32)
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 >
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+) >
<!ELEMENT Area (#PCDATA) >
<!-- Content of area is displayable label for the 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. -->
<title>XYZ Framizitzer Cicuit</title>
<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>
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
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.
W. Eliot Kimber (email@example.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"