[tei-council] Prefixing ids with "tei_"

[Martin Holmes]

On 13-01-18 11:59 AM, James Cummings wrote:
>
> Explain to me again why this isn't a one-off task where we run
> through the existing guidelines and prefix IDs and ptr and such? Then
> save them back to svn?
>
> I'm sure you explained it to me before but I've evidently forgotten.

I never thought that was what the task was. My assumption was that 
everyone wanted to keep the same ids (which are nice and short) 
throughout the source, and only change them when rendering the 
guidelines for the web, because it's only in the HTML output that this 
particular issue occurs; no reason presumably to burden the ePub output 
(for instance) with hundreds of longer ids.

I was following an approach Sebastian suggested in going the 
pre-processing route. If it turns out to be a waste of time, at least 
I've been looking at the stylesheet source for a couple of hours, which 
won't do me any harm.

> (About to watch Jeremy Hardy do standup)

Wot, live?

Cheers,
Martin
>
>
> JamesC
>
> Martin Holmes <mholmes at uvic.ca> wrote:
>
>
> Hi Lou
>
> On 13-01-18 11:29 AM, Lou Burnard wrote:
>> On 18/01/13 19:26, Martin Holmes wrote:
>>>> The wrinkle is that I can't find a way to do just the in-page
>>>> ids; I
>>> have to do the page filenames as well, because @xml:ids are
>>> intimately tied up with chapter page names. So where before we
>>> had SD.html, we now have tei_SD.html. This will be annoying to
>>> people who have bookmarked pages in the guidelines, but it could
>>> be mitigated by redirects.
>>
>> I think that's very annoying. It's also feature-creep -- we
>> embarked on the idea of modifying the IDs because they're
>> transparent, but the page identifiers are not.
>
> I know. I don't like it myself.
>
>>> If this change is unacceptable, then I think I'll have to give up
>>> on this approach, and go for post-processing the Guidelines pages
>>> after they're generated. I think that will add more time to the
>>> build than the pre-processing approach.
>>
>> really?
>
> I think so, because visiting every @xml:id, @target and @corresp in
> the source amounts to less work than visiting every @id and @href in
> the output; we generate many more links in processing than are
> explicitly there in the source. Also, processing the source amounts
> to processing a single file (p5.xml -> p5_prefixed.xml), whereas to
> process the output would require processing every html page.
>
>>> Let me know what you think. It may be that this whole idea is not
>>> worth the trouble.
>>
>> It's never seemed worth the effort to me, to tell the truth. We had
>> one problem, which we solved without going to these lengths.
>
> AFAIK, the problem is still there with at least one adblock list:
> the Fanboy list developers completely ignored our requests for a
> change. However, their list looks like it's moribund -- no updates
> since August.
>
> Cheers, Martin
>
> -- Martin Holmes University of Victoria Humanities Computing and
> Media Centre (mholmes at uvic.ca) -- tei-council mailing list
> tei-council at lists.village.Virginia.EDU
> http://lists.village.Virginia.EDU/mailman/listinfo/tei-council
>
> PLEASE NOTE: postings to this list are publicly archived .
>

-- 
Martin Holmes
University of Victoria Humanities Computing and Media Centre
(mholmes at uvic.ca)