On Thu, 1 Oct 1998 at 08:43:28 -0500, Michael Fox noted:
> One further coda to Daniel's reply. X Link is a recommendation for
> which, to my knowledge, there is no functional implementation as yet..
>
> The XLink functionality is built into version 1.0 of EAD but is not
> "turned on" unless someone "flips a switch" in the file ead.dtd.
On the subject of the support for linking in version 1.0, I note that
the elements which were present in the Beta DTD to provide support
for HyTime links (e.g. <ilink>, <nameloc>, <nmlist>) have been
removed.
I quite understand that it is anticipated that in the future this
functionality will be provided by an application which supports
XLink. Unfortunately the slower-than-hoped-for development of the
XML/XLink/XPointer/XSL standards themselves and of browser/viewer
support for them means that (as Michael Fox notes) there seems to be
no functional implementation of XLink at present.
However, tools like Softquad's Panorama viewer _do_ support a limited
subset of HyTime linking functionality. So, using the Beta DTD, I
could set up a link to an identified element (i.e. one with an ID
attribute) in another document using NAMELOC, along the following
lines:
[in source document]
!DOCTYPE ead ....
[
<!ENTITY TARGETDOC PUBLIC "-//University of Glasgow//DOCUMENT target
doc//EN" NDATA SGML >
]
<EAD>
....
<REF TARGET="xyz">click here to go</REF>
.....
<NAMELOC ID="xyz">
<NMLIST NAMETYPE="ELEMENT"
DOCORSUB="TARGETDOC">abc</NMLIST>
</NAMELOC>
[in target document]
...
<NOTE ID="abc"><P>End up here</P></NOTE>
...
Panorama's HyTime support renders this as a hypertext link to the
identified element in the target document.
What I would like to do is provide the above functionality using the
Version 1.0 markup. I would like to encode the document in such a way
that, in the interim while Panorama does not offer XLink support,
I can tell Panorama to recognise and process those elements as HyTime
forms, and then when the glorious day arrives, I can "flip the
switch" to XLink processing by altering the value of the
xlink/noxlink ignore/include parameter entities without needing to
modify the markup of the document body.
I think this requires that I do two things:
(i) establish the "correspondence" between the Beta version linkage
elements and attributes and the Version 1 linkage elements and
attributes;
(ii) add attributes to identify those Version 1 elements as the
appropriate HyTime forms.
I confess that I have not so far seen the Version 1 tag library so
I apologise in advance if that document addresses this issue! In the
meantime, I would appreciate any comments on my attempt at a
solution.
My reading of the new DTD and the XLink spec suggests that (and I
stress that these are my very tentative conclusions!):
(i) the <PTR>, <EXTPTR>, <REF>, and <EXTREF> elements continue to
function much as in the Beta version i.e. as the source anchor of the
link.
(ii) the Version 1 <LNKGRP> element is (amongst other things?) the
equivalent of the Beta <NAMELOC> element i.e. a container element for
a series of locators.
(iii) the Version 1 <PTRLOC>, <EXTPTRLOC>, <REFLOC> and
<EXTREFLOC> elements are equivalents to the Beta <NMLIST>.
So, to replicate the functionality of the example above, I need
something like:
!DOCTYPE ead ....
[
<!ENTITY % simple 'HyTime NAME "clink" ' >
<!ENTITY % extended 'HyTime NAME "nameloc" ' >
<!ENTITY % locator 'HyTime NAME "nmlist"
docorsub ENTITY #IMPLIED
nametype (entity |element) #REQUIRED' >
<!ENTITY TARGETDOC PUBLIC "-//University of Glasgow//DOCUMENT target
doc//EN" NDATA SGML >
]
<EAD>
....
<REF TARGET="xyz">click here to go</REF>
.....
<LINKGRP ID="xyz">
<EXTREFLOC NAMETYPE="ELEMENT"
DOCORSUB="TARGETDOC"
ENTITYREF="TARGETDOC">abc</EXTREFLOC> </LINKGRP>
Panorama seems to process this as I wanted, and replicates the
functionality provided by the Beta DTD's nameloc case. But I'm left
with the suspicion that I'm bending the way in which the markup was
intended to be applied in order to achieve this!
Some questions:
(i) is it valid to establish that correspondence between the XLink
and HyTime elements or am I rather jumping the gun and
oversimplifying things?
(ii) is EXTREFLOC the appropriate element to use in this context?
(iii) I found myself having to introduce two additional attributes
for EXTREFLOC. Firstly, I added DOCORSUB because that is the default
attribute name which the HyTime NMLIST form uses for the attribute
whose value identifies the target entity, rather than ENTITYREF.
Secondly I added NAMETYPE, which is required by the HyTime form but
for which I couldn't identify a corresponding attribute in the
XLink-oriented declarations. I tried remapping attribute names (and
so avoiding the addition of these two attributes) using the HyNames
attribute, but I couldn't seen to get Panorama to act on it. The
addition of these two attributes means, of course, that when, in 12
months time (he said optimistically), I "flip the switch" to go over
to XLink-based processing, I'm left with invalid markup - which
rather defeats the object of this exercise!
I feel sure I am missing something rather obvious and that there must
be a simpler answer to this problem and I would appreciate anyone
pointing it out to me!
My basic questions are:
How can I implement a reference/link to an identified element located
in a separate SGML-encoded document using Version 1? What is (or will
be) the appropriate markup for use with XLink? Given that Panorama
does not yet support XLink, but does have some HyTime support, can I
instruct it to process these XLink forms as HyTime forms in order to
get that functionality now?
Thanks in advance.
Pete Johnston
====================================================
Pete Johnston (Effective Records Management Project)
Archives & Business Records Centre
University of Glasgow
77-81 Dumbarton Road
Glasgow G11 6PP E-Mail: [log in to unmask]
Scotland, U.K. URL: http://www.gla.ac.uk/InfoStrat/ERM/
Tel: (UK) 0141 339 8855 ext. 2166 or (UK) 0141-330-4159
Fax: (UK) 0141-330-4158
|
