In response to Anne Mitchell's post of last month:
Sorry this is so late, but I wanted to point out another option for
your Photographer Index markup:
<index><indexentry>
<name>Acme Newspicture/Acme Photo: LOT 13074 <ptr target=3D"LOT13074">;
LOT 13088 <ptr TARGET=3D"LOT13088">; LOT 13089 </name> <ptr TARGET=3D"LOT13=
089">
</indexentry></index>
Putting the final <ptr> outside the <name> is ugly but necessary because
<indexentry>'s must have both a name-type thing and a pointer-type thing
to validate.
Having need for the <index> element myself, I agree with your pleas for
improvement of its present definition: <indexentry>'s should not _require_
<ptr> elements in them, and should _allow_ for any type of linking
element I might need.
By the way, is anyone out there keeping track of these requests for
discussion when the beta test period is over? Is there any mechanism=20
for changes in place now? Thanks,
___________________________________________________________________________=
__
MacKenzie Smith [log in to unmask]
du
Office for Information Systems (617)495-3724
Harvard University Library %\%\%\%\%\%\%\%\%\%\%\%\%=
\%
---------------------------------------------------------------------------=
--
On Thu, 23 May 1996, Anne Mitchell wrote:
>=20
> While tagging the NAACP finding aid (with alpha EAD), I ran into=20
> a snag using the index elements. Our index contains a list of=20
> photographers and studios, followed by call numbers.=20
>=20
> Here is our first attempt at tagging using <PTR>s and <PTRGRP>s: =20
>=20
> <ADD><INDEX><HEAD>Photographer Index</HEAD>
> =09<P>Names of photographers and studios . . .</P>
> <INDEXENTRY><NAME>A.L. Adams Photo Studio--Atlanta, Ga.: LOT 13076
> </NAME><PTR TARGET=3D"LOT13076"></INDEXENTRY>
> <INDEXENTRY><NAME>Acme Newspicture/Acme Photo: LOT 13074;=20
> LOT 13088; LOT 13089</NAME><PTRGRP><PTR TARGET=3D"LOT13074">
> <PTR TARGET=3D"LOT13088"><PTR TARGET=3D"LOT13089"></PTRGRP></INDEXENTRY>
> </INDEX></ADD>
>=20
> This produced an awkward display of pointers which were grouped=20
> following the list of call numbers. It looked something like this:
> =20
> Photographer Index
>=20
> =09Names of photographers and studios . . .
>=20
> A.L. Adams Photo Studio--Atlanta, Ga.: LOT 13076 --> =FE
> Acme Newspicture/Acme Photo: LOT 13074; LOT 13088; LOT 13089.=20
> -->=FE
> -->=FE
> -->=FE
>=20
> Because <PTRGRP>s can only contain <PTR>s, there is no way to=20
> intersperse the pointers so that they are directly next to the=20
> item to which they refer, which makes it impossible to select=20
> the correct pointer from a large <PTRGRP>. Also, elements within=20
> <INDEXENTRY> are not repeatable (so you can't have name, call#;=20
> name, call# repeating within <INDEXENTRY>). It's also more=20
> direct to have the link from the text of the call number rather=20
> than from a target following it.
>=20
> Here is tagging from our second attempt:
>=20
> <ADD><INDEX><HEAD>Photographer Index</HEAD>
> <P>Names of photographers and studios . . . </P>
> <LIST>
> <ITEM>A.L. Adams Photo Studio--Atlanta, Ga.:<REF=20
> TARGET=3D"LOT13076">LOT 13076</REF></ITEM>
> <ITEM>Acme Newspicture/Acme Photo:<REF TARGET=3D"LOT13074">
> LOT 13074;</REF><REF TARGET=3D"LOT13088">LOT 13088;</REF>
> <REF TARGET=3D"LOT13089">LOT 13089</REF></ITEM>
> </LIST>
> </INDEX>
>=20
> This wouldn't parse because <INDEXENTRY> is a required element=20
> in <INDEX>. This is obvious in the DTD, but not completely=20
> clear in the tag library, and the draft guidelines say=20
> <INDEXENTRY> is optional and repeatable. The idea with this=20
> approach was that we were not satisfyed with pointers, so we=20
> looked for a way to use <REF>s instead. <LIST>s are paragraph-level=20
> elements and can contain <ITEM>s which can contain <REF>s, so=20
> this seemed like a viable alternative.
>=20
>=20
> Finally, we cheated a bit and used <DIV> instead of <INDEX>
> so we could use the <REF>s
>=20
> <ADD><DIV><HEAD>Photographer Index</HEAD>
>=20
> <P>Names of photographers and studios . . . </P>
>=20
> <LIST>
> <ITEM>A.L. Adams Photo Studio--Atlanta, Ga.:<REF TARGET=3D"LOT13076">
> LOT 13076</REF></ITEM>
> <ITEM>Acme Newspicture/Acme Photo:<REF TARGET=3D"LOT13074">LOT 13074;
> </REF><REF TARGET=3D"LOT13088">LOT 13088;</REF><REF TARGET=3D"LOT13089">L=
OT
> 13089</REF></ITEM>
> </LIST></DIV></ADD>
>=20
> The display looks something like this (with call#s underlined/emphasized)=
:
>=20
> Photographer Index
>=20
> Names of photographers and studios . . .=20
>=20
> A.L. Adams Photo Studio--Atlanta, Ga.: LOT 13076
> Acme Newspicture/Acme Photo: LOT 13074; LOT 13088; LOT 13089
> =20
> I would appreciate any insight into why <INDEX> requires=20
> <INDEXENTRY>, with only <PTR> or <PTRGRP> available for=20
> links? Why not make structure of <INDEX> more like a=20
> <LIST>, or make it possible to use <LIST> in an <INDEX>. =20
> Also, maybe I'm missing a key point of understanding with=20
> the use of <PTR>s, but why can't they be a more <REF>like=20
> linking mechanism? I find the group display of pointers using=20
> <PTRGRP> baffling.
>=20
> Thanks in advance for any help!
>=20
>=20
> Anne Mitchell
> Prints and Photographs Division
> Library of Congress
>=20
|
