Michael (et al.),
One of the problems I have found using generate-id(), is that it is dependent on the XML source document when it generates unique strings. Further, the id string produced is dependent on either the XPATH statement given to the function, or if left empty the function returns the unique id for the context node of the XML source document.

The problem is that in most cases, I am generating many HTML (or whatever markup) elements in my output dependent on one or from the context of one node in my XML source (an EAD component for example).

Therefore, the generate-id() function is creating unqiue ids based on the assumption that you will have a 1-to-1 relationship between the XML source nodes and the HTML output (or whatever markup).

The result (depending on how you are writing your XSLT templates handling the XML Source document) can be repeated id values in your output.

Many will avoid this by either writing XPath statements to the unique elements they wish to create ids for, or writing their templates so that the context node of the template will return a unique string every time the template is called.

For myself, I dont' use this function. The reasons are as follows:
1. I don't wish to be constrained when I write my stylesheet to figuring out what the function will do based on how I am transforming the XML Source document. Frankly, I don't  want my output to be directly dependent on the XML Source (that is why I am writing the stylesheet!).
2. I don't want to write XPath statements that target known unique nodes in the XML Source to get a unique id string from the function. I would rather not have to figure out what each EAD document has  or does not have. The purpose of my stylesheet is to crunch may different EAD documents (I have a life already) without previewing each of them. (If the element does not exist, the function returns an empty set.)

So, what is my solution?

There are unique values for every EAD document.

1. total sum of elements (or nodes).
2. eadid (persistent identifier)

These two values can be used to create ids for any EAD document.

1. A global variable can be set in the stylesheet to get a count of all nodes in the EAD document. This value can be used at anyplace in the stylesheet as a base value to create a unique number. (imported stylesheet issues may have to pass params or recount)
2. Other syntax can be used to build this string to readily identify the ID as created by the stylesheet.

Finally, building a TOC is very problematic. The stylesheet writer must face the fact that this is an artificially created list that does not exist in the original EAD code. Therefore, building and creating @IDs must ultimately be dependent on the stylesheet not the source code. Binding the generation of id values on the these unique variables will result in unique ids for any and every EAD document. (Of course not having a eadid persistent identifier will make things rough. You might use the file name instead.)

Note: When you generate TOCs, be sure to remove any @ID attributes from elements that you may bring into the TOC (emph/@id). If you don't, you will have repeated @IDs in your HTML and your links will fail.

Anyway, my two cents.

Mike Ferrando
Library Technician
Library of Congress
Washington, DC
(202) 707-4454

----- Original Message ----
From: "Fox, Michael" <[log in to unmask]>
To: [log in to unmask]
Sent: Monday, April 16, 2007 10:10:45 AM
Subject: Re: Table of Contents links to c01 and c02 tags

Good morning, 

The EAD Cookbook stylesheets do use the XSLT generate-id() to link the table of contents with the body of the document.  

I disagree with Michele's assertion that this is problematic for the table of contents.  The link in the table of contents references the id that has been generated for the portion of the document to which it is being linked.  This code in the table of contents will always generate the same id value at both the source and target because the former merely references the latter.  Being part of a <xsl:for-each> loop. it is always relative.

    <a href="#{generate-id(archdesc/did/head)}">
        <xsl:value-of select="archdesc/did/head"/>
    </a>

Internal links are admittedly more problematic and explict @id attributes at the link target are clearly the most reliable option.

However, here's a code challenge for someone who wants to try a more hands-off approach.

In the case of linking <c01> titles in an <arrangement> statement with their descriptions in <dsc>, could one use the <xsl:number> feature to number both the titles in <arrangement> and the <c01> elements in <dsc> and then use the generate-id() to link them based on the number assigned?   This assumes of course that the titles are listed in <arrangment> in the same order as they appear in <dsc>.  


This would be a more sophisticated approach than the one currently employed in the Cookbook which simply assigns numbers.

    <xsl:template match="archdesc/scopecontent/arrangement/list/item | archdesc/arrangement/list/item">
        <div style="margin-left:50pt">
            <a>
                <xsl:attribute name="href">#series<xsl:number></xsl:number>
                </xsl:attribute>
                <xsl:apply-templates></xsl:apply-templates>
            </a>
        </div>
    </xsl:template> 

In the end, these all depend on stylesheet support.


Michael Fox

-----Original Message-----
From: Encoded Archival Description List [mailto:[log in to unmask]]On Behalf Of
MicheleR
Sent: Saturday, April 14, 2007 11:03 AM
To: [log in to unmask]
Subject: Re: Table of Contents links to c01 and c02 tags


Hi Jordon --

It's a two-part process; you didn't mention which part you need, so 
here's both.  Part 1 is making sure that the c01s and c02s in the body 
of the inventory have an ID to link to; this is done in the dsc# style 
sheet.  Part 2 is adding a listing in the TOC that links to the correct 
IDs; that's done in the eadcbs# style sheet.  IDs can be fixed (via use 
of the id attribute in EAD) or generated during transformation; the 
former is obviously more reliable.

The code for part 1, inserting the ID in the body of the inventory 
resides in whatever dsc style sheet you're using and looks something 
like this for fixed IDs:

    <xsl:if test="@id">
       <a id="{@id}">
          (blah blah, usually unittitle goes here)
       </a>
    </xsl:if>

Part 2, putting the listing in the TOC, is done something like so for 
fixed IDs:

<xsl:for-each select="archdesc/dsc/c01[@level='series' or 
@level='subseries'] or archdesc/dsc/c02[@level='subseries']">
    <p>
       <b>
          <a href="#{@id}">
             (blah blah, usually unittitle goes here)
          </a>
       <b>
    </p>


There is a generate-id function that will create ids during transformation:

<a href="#{generate-id(.)}">

but it can be problematic for a couple of reasons.  First, since the IDs 
are recreated every time you run a transformation you don't know what 
they'll be at the time you're creating the TOC. Second, if you have any 
internal links to c01s or c02s, you won't know what href to use in your 
EAD since the IDs haven't yet been generated and may be different each time.

If you're really set on generating IDs during transformation, a more 
reliable way is to generate IDs by counting the number of c01s/c02s, 
something like this:

<xsl:attribute name="href">
    <xsl:text>#series</xsl:text>
    <xsl:number count="c01" from="dsc"/>
</xsl:attribute>

This will work easily for c01s since there's only one set of c01 tags at 
the top level, but you'd have to somehow differentiate between the c02s 
that are children of different c01s.

Caveat: if you're employing that feature that automatically links lists 
in the <arrangement> element to their respective inventory items (in 
eadcbs9 it's the section that begins "<!-- The next three templates 
format a list within an arrangement..."), that uses the "count" function 
and switching to the fixed-id method will require repairs to that feature.

Michele

Jordon Steele wrote:
> Hello,
>  
> Does anyone know what code to use to create links between series and 
> subseries titles in the table of contents to the corresponding c01 and 
> c02 tags in the body of the finding aid?  I think I tweaked this part of 
> the code on my stylesheet a little too much, and I forgot what the 
> original code was! 
>  
> If it helps, I'm using a customized version of eadcbs9.xsl as my primary 
> stylesheet.
>  
> Thanks,
>  
> Jordon
>  
> Jordon Steele
> Archivist
> Biddle Law Library
> University of Pennsylvania Law School
> (215) 898-5011
>  




__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com