Re: pgsql: Doc: add XML ID attributes to and tags.
От | Brar Piening |
---|---|
Тема | Re: pgsql: Doc: add XML ID attributes to |
Дата | |
Msg-id | ccea6e06-83d9-8fc5-7b60-1a26e21ba549@gmx.de обсуждение исходный текст |
Ответ на |
Re: pgsql: Doc: add XML ID attributes to |
Список | pgsql-hackers |
On 12.01.2023 at 00:05, Tom Lane wrote: > Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes: >> Any reason the new ids in create_database.sgml deviate from the normal >> naming schemes used everywhere else? Is it to preserve the existing >> create-database-strategy? Maybe we should rename that one and make the >> new ones consistent? I don't remember every single choice I made but the general goal was to at least stay consistent within a varlist/[sub]section/file/chapter and *never* change pre-existing ids since somebody may already be pointing to them. After all it is just an identifier that is supposed to be unique and should not hurt our aesthetic feelings too much. The consistency is mostly because we tend to like it and maybe also to avoid collisions when making up new ids but I doubt that anybody will ever try to remember an id or infer one form knowledge about the thing it should be pointing at. I consider it a pretty opaque string that is meant for copy-paste from a browser to some editing window. It is all in our head and as a matter of fact we could be using UUIDs as Ids and save us from any further consistency issues. It's just that they look so ugly. > You'd have to ask Brar that, I didn't question his choices too much. > > I have no objection to changing things as you suggest.I'm hesitant to > rename very many pre-existing IDs for fear of breaking peoples' bookmarks, > but changing create-database-strategy doesn't seem like a big deal. Personally I'd only d this for ids that haven't been "released" as official documentation (even as "devel" since the new things tend to attract more discussions and probably linking). I very much consider URLs as UI and go long ways to keep them consistent (HTTP 3xx is a friend of mine) as you never know who might be pointing at them from where and making them a moving target defeats their purpose and probably hurt more than some inconsistency. Regards, Brar
В списке pgsql-hackers по дате отправления: