Print

Print


Richard Higgins --

SGML can _describe_ such links as you want, although it is up to the
viewer to support them.

Panorama does support TEI Extended Pointer Syntax for linking, which is
what you need. Whether the EAD as delivered provides for this I can't say
offhand (I'm working at home today), but in the TEI form, the link is
provided for in (reduced) HyTime fashion. The relevant attributes on the
TEI XREF element (the EAD analog would be EXTREF) are:

<!ATTLIST xref
     doc ENTITY #IMPLIED
     from CDATA "ROOT"
     to CDATA "DITTO"
>

In the simple implementation you describe, the target document would be
declared as an entity and referred to by the DOC attribute, and the ID of
the target element (the item-level <c>) would appear in the FROM
attribute. (It works leaving the TO attribute as default -- you could
change FROM to TARGET and be done with it.) Panorama can then provide a
link as instructed by an ATTLINK processing instruction (as described in
the manual).

I hope this helps. Such a link as you described is provided in CETH's
pilot implementation of the Griffis Collection Electronic Access Project
(http://www.ceth.rutgers.edu/projects/griffis/project.htm), although the
link there is not between EAD documents, but from a TEI document
transcription back into the finding aid which lists it.

Good luck --

Wendell Piez
Center for Electronic Texts in the Humanities
[log in to unmask]

___&&__&_&___&_&__&&&__&____&__&&____&&&&___&__&_&&_____&__&__&&_____&_&&___

On Mon, 20 Jan 1997, Richard Higgins wrote:

> Hello
>
> Every month or so I seem to post this, in the hope that someone will provide the solution.  Each time I
> get another fragment of an answer, but end up no nearer to success.  Trying other SGML lists does not
> seem to have elicited much progress.
>
> Working on the theory that I would need to provide links to items within handlists, and cross references
> between them, I incorporated unique ID attributes into each item level descritpion in EAD lists as I went
> along.  By following a pattern it meant that I could put in a cross reference to an item before reaching it
> as I could predict what it would be.  This works fine within a single document.
>
> The primary intention of this, however, was to provide anchors for references from other handlists as I
> proceesed them, as so many of our collections are connected, and it seemed a prime requirement to be
> able to hyperlink all these references together. This is a fundamental way of providing information about
> collections within the context of the repository, and should also allow cataloguers elsewhere to refer to
> individual items.
>
> The first problem was that no element in EAD allowed for a hypertext link to an ID in another file, but
> this could be fixed (?).  The more enquiries I make about ID references between documents, the more
> contradictory the responses: probably many SGML documents are not required to link to external text
> files except to include them in their entirety, but this will be required in handlists.
>
> One problem to resolve is whether it is a viewer or an SGML problem - does Panorama PRO simply not
> allow this viewing pattern: sadly no response from Softquad on that one.
>
> Others state that Hytime links are the solution, but try finding one that works beyond the tiny example
> that comes with Panorama PRO and only links within the same document.  In fact some say Hytime
> should be avoided as it does not provide as reliable an anchor as an ID, while elsewhere it is stated that
> it is impossible to make links to ID's in other documents.  I tried using the original Findaid DTD, but this
> didn't work either.
> SO....
> Does SGML allow links to an ID attribute in another SGML document?
> If so, can it be viewed in Panorama - i.e. where is there a working example that can be browsed.
> If not, is Hytime the answer, and where can a working example with links between documents be viewed?
>
> It is an added difficulty of SGML that there are two parts to a problem with it - the SGML and the viewer.
>  It would be nice to get as far as eliminating one side of the equation.
>
> Thanks
>
> Richard Higgins
> Durham University Library
>