Stability of book URLs

[Max Bowsher]

Max Bowsher wrote:
>> Max Bowsher wrote:
>>> Currently, URLs to parts of the book suffer from a stability problem.
>>>
>>> If we add or delete sections (or worse, chapters!), then many URLs
>>> pointing to specific sections will be broken.
>>>
>>>
>>> To fix this, I propose the following:
>>>
>>> Step 1: Enable the parameter "use.id.as.filename"
>>> This will cause each file produced in the chunked HTML to take a name
>>> based on the id attribute of the XML element which caused the chunk,
>>> instead of the plain sequential system used currently.
>>>
>>> Step 2: Migrate the values of id attributes away from the primarily
>>> numerical system in use now, instead using descriptive names.
>
> C. Michael Pilato wrote:
>> To quote something I've been hearing around the Chicago office lately
>> (but whose source I do not know):
>>
>>    "I'm intrigued by your ideas, and would like to subscribe to your
>>    newsletter."
>>
>> I would like to get clearance from O'Reilly on this, first, though.  We
>> used that scheme because it was described as The Way To Do It (nevermind
>> it was always a pain in the buttocks...).
>
> OK.
>
> In its simplest form, the question we need asked is "Do you place any
> restrictions on the content of 'id' attributes?".

Replying to myself...

It just occurred to me to look at readme-dblite.html.
It essentially says that O'Reilly might or might not automatically replace 
id attributes with autogenerated ones, and hints that their reasons for 
deciding to do so would be due to missing id attributes, or a scheme which 
did not make sense to anyone but the author.

So, then I took a look at the values we are actually using. They correspond 
approximately, but *not* completely to O'Reilly's default autogenerated 
ones.


A related question for the book authors:
Sections (especially subsections) will clearly come and go as subversion 
develops, but how mutable is that chapter/appendix numbering expected to be?

Max.