всё же ещё немного скажу про name и рендеринг
базу вполне можно представить как набор нулей и единиц
но так как человеку такой формат данных воспринимать сложно, появилось множество клиентов базы данных - поисковых систем, навигаторов, карт, которые обрабатывают информацию базы и переводят её в понятный человеку вид
даже если предположить что базу люди будут читать исключительно как xml документ, всё равно просмотрщик будет выполнять работу по представлению данных
именно поэтому не стоит недооценивать важность представления данных
грубо процесс потребления данных можно изобразить так:
чтение с базы → вычисления/обработка → визуализация результата
конечный пользователь будет смотреть именно на результат
и как раз его качество оценивать
но для того чтобы результат оправдал ожидания, мало сделать хорошие алгоритмы в клиенте
алгоритмам надо предоставить годные данные - как в плане архитектуры/логичности, так и корректности
однако смотря на набор битов, будет сложно определить как же их всё же лучше организовать
для этого как раз и прийдётся задуматься о потреблении - какая же организация данных позволит их лучше всего обработать?
так как было создано множество разных потребителей, то учитывать обработку данных каким-то одним из них некорректно по отношению к другим
поэтому приходится искать компромиссы
раз решить что важнее - база или её клиенты - невозможно, то приходится рассматривать каждый случай отдельно
в результате анализа можно сделать такие выводы:
- Метод представления данных в базе некорректен, для улучшения обработки данных его нужно менять [color=#888](пишется пропозал для сообщества)[/color]
- Метод использования данных в клиенте некорректен, для улучшения результата необходимо исправлять клиент [color=#888](пишется багрепорт авторам)[/color]
- Определить причину проблемы оказалось сложно. Возможные варианты: думать дальше над причиной, попытаться найти такое представление данных, которое не нарушит логику базы, но при этом исправит поведение клиента.
с первыми двумя пунктами всё понятно - данные базы до принятия оптимального решения никто не трогает, соответственно и испортить ничего нельзя. третий же, с одной стороны, позволяет на некоторое время забыть о проблеме, обеспечив совместимость (что довольно ценно, так как результат виден сразу), но, с другой стороны, при неумелом использовании, может как нарушить совместимость с другими клиентами, так и просто ухудшить качество данных
возвращаясь к name:
причины конфликта являются как социальными, так и техническими
технически, у многих пользователей отсутствует возможность получить результат обработки базы на нужном им языке
в результате, так как клиент они исправить не могут, для достижения нужного им результата, они меняют базу
проблема ли это с социальной и технической точки зрения?
с социальной - однозначно да, так как удобство для себя во многих случаях приводит к неудобству для соседа - вот уже и проблема
с технической же особых проблем нет - смена языка в теге, который изначально не привязан к языку, никаких алгоритмов не сломает. если же какой-то клиент понадеется на язык name тега и потерпит неудачу с этим, то для него есть альтернативный путь - name:xx теги, которые намного меньше вовлечены в социальный конфликт