Stability of book URLs
Max Bowsher
maxb at ukf.net
Thu Apr 21 07:08:06 CDT 2005
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.
More information about the svnbook-dev
mailing list