[tei-council] Prefacing ids with "tei_"

[Piotr Bański]

Hi Martin,

This may be a classic case of my missing the point, but something
doesn't click in my mind, so I'd better comment on that, just in case:

On 23/04/12 20:48, Martin Holmes wrote:
> I'm planning to make a significant number of changes to Sebastian's 
> stylesheets to implement our decision to preface all ids in the web 
> output with "tei_", in an effort to avoid the problems caused by AdBlock 
> Plus. Before I do, having looked at the code, there are a couple of 
> things I wanted to get some feedback on:
> 
> 1. Generated ids. There are some places in which ids in the output are 
> generated using the XPath generate-id() function:
[..]
> These result in ids that look like random sequences of characters. Do we 
> need to preface these with "tei_"? My instinct says yes -- after all, 
> such a random sequence is perfectly likely to end up with content which 
> might trigger an AdBlock filter, so we might as well protect it in the 
> normal way.

I understood that "msad" triggered the false positive, and the (arguable
and, IIRC, argued) decision was for the TEI to adjust to AdBlock.

But if the problem was the matching of the entire string "msad" only (as
opposed to "tei_msad"), then i am led to conclude that a substring match
does not trigger the false positive. If that is true, then
generated-ids() can't within reasonable probability generate an
offensive string, and only that string (without extra characters).

As to your second question, I'd say the prefix introduces a layer of
safety indeed. But I'm not sure to what extent we as the Council need to
bother of someone using silly @n atts as the basis for a silly algorithm
of @n->@id. We might end up being overprotective here.

Best,

  P.



> 
> 2. @n attributes. There's one place where the @n attribute can be used 
> to create an id attribute in the output (in textstructure.xsl, code 
> below). Should this also be prefaced by "tei_"? I'm not sure about this, 
> because depending on the contents of the @n, the result might be 
> puzzling. On the other hand, I don't think that @n can be relied upon to 
> work as an id attribute anyway, can it?
> 
> <xsl:variable name="identifier">
>           <xsl:text>App</xsl:text>
>           <xsl:choose>
> 	   <xsl:when test="@xml:id">
> 	     <xsl:value-of select="@xml:id"/>
> 	   </xsl:when>
> 	   <xsl:when test="@n">
> 	     <xsl:value-of select="@n"/>
> 	   </xsl:when>
> 	   <xsl:otherwise>
> 	     <xsl:number count="tei:app" level="any"/>
> 	   </xsl:otherwise>
>           </xsl:choose>
>        </xsl:variable>
> 
>        <xsl:choose>
>         <xsl:when test="$footnoteFile='true'">
> 	 <a class="notelink" href="{$masterFile}-notes.html#{$identifier}">
> 	   <sup>
> 	     <xsl:call-template name="appN"/>
> 	   </sup>
> 	 </a>
>         </xsl:when>
>         <xsl:otherwise>
> 	 <a class="notelink" href="#{$identifier}">
> 	   <sup>
> 	     <xsl:call-template name="appN"/>
> 	   </sup>
> 	 </a>
>         </xsl:otherwise>
>        </xsl:choose>
> 
> Cheers,
> Martin