Журнал о системах электронного документооборота (СЭД)
Разные задачи в ECM

Версионность документов в приложении к визуальному контенту

  22 комментариев Добавить в закладки

Насколько можно понимать современные тенденции, в ECM-системах считается моветоном НЕ поддерживать версионность документов.

Версии отражают состояние документа на различных стадиях его жизненного цикла, позволяют отследить эволюцию документа: как проект нового изделия пришёл из состояния «Во мне миллиард страниц, и на каждой приводится по 4 варианта решения каждой микроскопической задачи, из которых вам, уважаемый рецензент, нужно выбрать наиболее верное» в состояние «Я хороший проект нового изделия. Во мне всё правильно, логично и красиво». Версии дают нам возможность в дальнейшем вернуться к тому, на какой стадии было принято некое спорное решение, каким образом оно аргументировалось, какие размышления привели к его принятию. Версии позволяют показать, например, удачное завершение сделки, если одной из версий договора является его скан-образ с живой подписью и печатью.

Очень поддерживаю выделение версий текстового контента, однако, что делать с контентом визуальным? Как правильно организовать работу с визуальным контентом в условиях поддержки ECM-системой версионности документов?

Допустим, некий Василий Пупычев вот уже 50 лет работает в одной и той же фирме, понятно, что с течением времени его внешний вид изменяется, и по фотографии 20-летнего юнца мы с трудом сможем опознать вот уже 70-летнего Василия. Поэтому Василию, скорее всего, придётся временами обновлять своё фото, которое отображается, например, в разделе сотрудников на корпоративном портале. И вот вопрос: фотография Василия в 70 лет – это уже другой документ или версия документа с фотографией Василия в 50 лет? Думается, что если это фотография для портала, то, скорее всего, версия, ведь она какбе отражает жизненный цикл… в данном случае, Василия. Но с другой стороны, правильно ли перетирать 70-летним Василием Василия 50-летнего, ведь обычно всех интересует последняя версия и 50-летнего вообще никто смотреть не будет, если это будет не последняя версия?

Фотографии одного и того же здания в один и тот же день и примерно в одно и то же время с фасада и с торца – это разные документы или версии одного документа?

Портретная фотография и фотография в полный рост одного и того же человека, сделанные в ходе одной и той же фотосессии – это разные документы или версии одного документа? А если они были сделаны в разных фотосессиях, но участвуют только совместно в неком конкурсе, которая проводит компания, это версии или отдельные документы?

Быть может, для визуального контента повсеместно нужен какой-то иной механизм работы. Ведь для изображений, в отличие, от текстовых документов каждая последующая версия равнозначна любой предыдущей, и «последняя» не всегда значит самая «актуальная» (как, например, в случае со зданием). Поэтому ECM-системе, на мой взгляд, нужно уметь отделять визуальный контент от любого другого и предлагать иной способ взаимодействия с ним. Такой, который позволит, во-первых, избежать безумного разрастания количества документов в системе с появлением новых фотографий, во-вторых, не заставит пользователя рассуждать, какая из фотографий актуальнее, чтобы она в документе последней версией, ну и наконец, в-третьих, просто сделает и поиск изображений, и саму жизнь проще и красивее.

Ещё материалы автора
Похожие записи
Комментарии (22)
Дамир Галимов 20 января 2011 г. 16:56  

На мой взгляд, здесь имеет место подмена понятий. Для текстовых документов речь идет об изменении содержания со временем, а для графических почему-то упоминается "Портретная фотография и фотография в полный рост одного и того же человека" или "Фотографии одного и того же здания ... с фасада и с торца". Для корректности сравнения надо вспомнить что и текстовые документы почти никогда не существуют поодиночке и часто некоторое заявление на льготу неотделимо, например, от анкеты заявителя, а проект нового изделия от маркетингового исследования и расчета экономического эффекта. Конечно, текстовые документы можно "склеить" в один документ, но это усложнит поиск и... отслеживание изменения документа со временем, т.е. формирование новых версий.

Поэтому предлагаю не путать понятия "версии документа", отражающие изменение содержания документа со временем и "комплект документов", т.е. совокупность взаимосвязанных документов в данный момент времени. В этом случае фотографии Василия Пупычев в разные годы его жизни - это версии документа, а вот фотографии здания со всех ракурсов - это комплект. Иными словами основным критерием является время.

Теперь попробуем добавить ко времени еще одно изменение - формат документа. Кто сказал, что текстовый документ - это не графический документ? Текстовый документ может существовать в исходном, редактируемом виде, в PDF для публикации на сайт, в отсканированом, с "живыми" подписями и печатями контрагента и т.п. И это все один документ в один момент времени с одним текстом но в разных форматах. Вроде и не комплект, но и не версии. Кто-то в этом случае вводит понятия версий и подверсий, мажорных и минорных версий, древовидную структуру версий...

А дальше все становится еще интереснее, т.к. предстоит ответить на вопрос, а как удобнее это реализовать? Например, комплект (использую термин, который описал выше) фотографий удобнее просматривать в едином окне, перелистывая их друг за другом или в режиме слайд-шоу, а не открывая каждое изображение двойным кликом мыши на документе. А вот комплект текстовых документов, как правило, враз весь просматривать не требуется, достаточно открыть в каждый конкретный момент лишь один текст из комплекта. А комплект документов разного формата (где заявление на льготу соседствует со сканами паспорта и пенсионного свидетельства, например)?

Следующим шагом в размышлениях будет вопрос о версии комплекта :-) Приведу пример: допустим мы хотим получить кредит на любые цели. Надо подготовить десяток-другой документов. Подготовили, распечатали, подали в банк, получили кредит, расплатились, получили хорошую кредитную историю. Проходит время. Возникла потребность в новом кредите в том же банке на те же цели. Половина документов от старого комплекта подходит без изменений (сканы паспорта, справка о составе семьи и пр.), остальные документы требуют лишь незначительных изменений (прописать другие даты в заявлениях, указать новую сумму, внести сведения о своей положительно кредитной истории от прошлого кредита и т.п.). Вот как тут быть? Создавать копии каждого документа из комплекта и прервать связь документа со своим предком или же удобнее было бы создать версию комплекта в целом, внеся в некоторые документы этой версии комплекта требуемые изменения?

В общем к вопросам поставленным в записи блога я добавил еще несколько, дабы решать задачу комплексно.

Станислав Ким 22 января 2011 г. 17:13  

 

Меня переполняют эмоции, постараюсь быть максимально сдержанным, заранее извините, если кого случайно обижу.

 

Ольга, крайне рекомендую вам еще раз разобраться в жизненных циклах документов, а также определиться с понятиями документ/record(s), проект документа,представление и версионность и на каком этапе жизненного цикла последнее имеет место быть. Почитайте пожалуста стандарты MoReq, ISO 15489 (обе части), многочисленные послы на данную тему в форуме Docflow и PCWEEK (Колесов), блог коллег из Documentuma "Как переводить слово record" http://my-documentum.blogspot.com/2010/11/record.html, "Управление документами и управление записями – найдем 6 отличий" http://my-documentum.blogspot.com/2010/11/6.html Если бы идеи озвученные в данной статье мне выдал мой студент на экзамене по ECM, он получил бы неуд и пошел на допсу, т.к. это основные термины и понятия ECM и они даются на первых занятиях.

 

Едем дальше по порядку.

 

Скан-образ с «живой» подписью и печатью не является одной из версий документа. Это запись (record), неизменный документ, подтверждающий факт заключения сделки. Даже если что-то и будет меняться, то только в допниках, или на крайнем случае договор подменится и переподпишется.

 

Пример с фотографиями Василия вообще эзотерически выносит мозг. Вы хотите сказать, что Василий в 20 лет по его содержимому (контенту) = Василий в 70 лет? Или человек в 20 лет и он же в 50 — это просто версии одного и того же субъекта. Даже если бы Василий все это время пролежал в коме и практически не изменился, у данных субъектов и тем более их фотографий будет одна большая разница — возраст. Кстати, а что значит слово «какбэ»? Это новый термин?

 

С человеком все сложно, много философии, давайте про здания. Фотографии одного объекта, сделанные с разных ракурсов - абсолютно разные документы, а не версии одного и того же документа. На одной фотографии есть информация, которой нет на другой. Контент разный. Иначе по вашей логике все документы компании, начиная от Устава и учредительного договора, заканчивая сегодняшним счетом — версии одного документа, т.к. относятся к одной компании (зданию).

 

Ольга, вы перестанете путаться и путать других, когда поймете суть слова record(s). Не надо относиться к визуальному контенту как чему-то обособленному, иначе придется еще много чего выделять.

 

Мое мнение. Пост крайне слабый, содержит многочисленные исходные ошибки на которых строятся неверные выводы. Был крайне удивлен вашей должности, ИТ-аналитик одной из лидирующих СЭД компаний не имеет права писать такое.

 

 

Дамир, теперь с вами.

Вы говорите о «комплекте документов», о котором Ольга и не высказывалась. Вы также соглашаетесь со всеми ошибками Ольги в частности с тем, что документ с печатями — тоже версия документа. Дальше переходите на комплекты и не можете разобраться как работать с одним документом, используемым в разных комплектах и как относиться к комплектам на разные кредиты. Очень странно.

 

Если ИТ-аналитики ведущих СЭД-компаний не могут разобраться в основах СЭД, что же происходит с конечными клиентами?

Виктор Золотов 22 января 2011 г. 18:59  

К чему эмоции ).

  1. MoReq и иже с ним - лучше чем ничего, но все таки это не "библия" и ссылаться на него как на твердныню знания слишком... узко что-ли.
  2. У автора вопрос родился из жизни, и надо сказать что вопрос действительно актуальный.

К Станиславу. По договорам. Да, с точки зрения ЖЦ документа и Records Management вполне разумно что подписанный сторонами договор это "запись" и все такое...

 

Но представьте себе реальную и полномасштабную работу в СЭД. Что бы вот я делал?:

  1. Создам проект документа. Поставлю ЭЦП. Отправлю на согласование.
  2. Его, конечно, возьмут и завернут. Куда вносить правки? Разумно что в версию 2. За время согласования не типового договора по практике набежит не мало версий.
  3. И вот его подписали с двух сторон... Чисто с технической точки зрения да и с "интерфейсной", куда мне положить логично скан? А почему бы и не новой версией? Ну да, хочется говорить "как у них" ради бога, назовем эту последнюю версию "рекордом".

Надо обеспечить неизменность такой записи? ну заберем автоматически у всех права, "спишем" его в архив с установленными правилами хранения и уничтожения. Но технически - это просто версия. И это выглядит логичным. Это просто удобно - нашел документ, увидел что в нем "уже есть запись", надо - посмотрел предыдущие версии (к которым кстати также можно ограничить доступ).

 

С изображения, да и не только, как определить что есть версия, что есть новый документ... С трудом представляю рабочую инструкцию для сотрудников где было бы можно сформулировать когда как правильно делать. А значить все остается на уровне Методических инструкций. Как вариант: "Правки, вносимые в документ в процессе подготовки, согласования и утверждения, следует оформлять версиями. Актуализацию действующего документа так же рекомендуется оформлять версиями.".

А лучше прописать наиболее часто встречающиеся ситуации, например:

  • Правки договора вносим версиями, приложения и допники - отдельные документы.
  • Планы на месяц офрмляем разными документами.
  • Актуализация технологических документов - версиями

и т.д.

Т.е. все должно быть прежде всего логично ). И даже следовать стандартам надо не забывая про логику.

 

Станислав Ким 23 января 2011 г. 15:02  

 

1. MoReq и иже с ним нормативные документы, относящиеся к стандартам, добровольны и не обязательны к использованию/исполнению. Они формализуют отношения заказчика и исполнителя к предмету взаимодействия и дают точку опоры и уровень приемлемого качества. Кстати, не думал, что «библия» является твердыней знаний.

 

2. Я не говорю, что автор ситуацию высосал из пальца и вопрос конечно же актуальный. Однако, специалист, заявляемый как эксперт-аналитик должен как минимум владеть предметной областью, терминологией и базовыми понятиями. В данном посте я этого не увидел.

 

Хорошо, что вы согласились выделить документ с «живыми» подписями и печатями в отдельную категорию нежели драфты(проекты) данного документа.

 

Дальше ваши выкладки не понял. Напоминает мнение: «есть ПДД, но посмотрите на реальную действительность. Права покупаются, все ездят как хотят, пробки. О каком соблюдении ПДД может идти речь? И вообще у меня мигалка и мне удобно ездить по встречке.» Вы пытаетесь несоответствие определенным требованиям обосновать сложившейся практикой, удобством, реализованной функциональностью используемого продукта и т.д. Для описанных вами ситуаций кроме версий есть понятие статуса документа: проект, действует, отменен, заменен на. Как вы будете работать с этими документами в вашей системе и в качестве чего хранить и выводить — ваше личное дело, но как это преподносить пользователю и вещать на всю страну, извините.

 

P.S. Виктор, рад вашему появлению на данном блоге. Надеюсь, это не последний коммент и ваша активность по защите ИТ-молодежи, сложившихся традиций и логики будет замечена и оценена по достоинству ;) 

Виктор Золотов 23 января 2011 г. 20:27  

Ну так а в чем не соответствие стандарту?

Вот предположу, что для вас более "приемлема" такая архитектура - есть информационная система где создаются проекты документов, согласуются, утверждаются. А потом надо зафиксировать запись и переместить ее в "специализированное хранилище". Почему отдельно? Аргументы есть, да. Во-первых реквизиты могут быть отдельными и нужными только для хранения, безопасность повыше, так как изолировать все проще, проще искать в теории актуальные документы и т.д.

Вот в такой ситуации мы практически идеально выполним обсуждаемую часть требований? Т.е. условно введем жизненный цикл документа, и на его стадии условно называемая "Действующий" (в случае договора, например после подписания сторонами) будем делать по факту его клон который будем называть запись. И у это клона будут свои реквизиты, правила хранения, изъятия и уничтожения?

Мне самому такая система нравится, так как лучше защищает от ошибок как проектирования, так и пользования ИС.

Но на практике это целесообразно только тогда, когда в компании в силу не важно каких причин нет логически единой ECM. Типичный пример - SharePoint. Мы имеем шаблон сайта Document Center и Records Center. Функциональных отличий -  ну совсем минимум. Идейно - с документами творим что хотим в рабочих группах, а их как и библиотек сколько угодно, а вот потом уже перемещаем на хранение как запись.

А коллеги из DIRECTUM уже на уровне спинного мозга воспринимают ECM как вертикально интегрированную ИС (со всеми оговорками на распределенные системы и т.д.). И потому с вами "не на одной волне".

А вы Станислав, как раз напротив, имея потребность дифференцироваться - четко видите задачи отдельного хранения документа, и не годуете, как же они не видят. А им просто не надо, для них "записи" - это подмножество документов, поисковая выборка, если хотите. 

Так вот к стандарту и ПДД )...

Да, всем надо соблюдать ПДД, особенно если все знают о существовании ПДД и эти самые ПДД - одни. Но как там сформулирован вопрос в экзаменах? "С какой скоростью безопасно двигаться в потоке? - Со скоростью ниже разрешенной, - Со скоростью ранвой разрешенной или Со скоростью потока?".

Ответ принимаемый ГИБДД очевиден - со скоростью потока. Да, даже если вы нарушаете скоростной режим, главное ехать безопасно. И это примут в суде как основание для опротестование штрафа.

Мораль - соблюдать стандарты надо, но до тех пор пока это выгодно. В хорошем смысле этого слова ). 

Максим Галимов 24 января 2011 г. 09:54  

Постараюсь примирить все стороны.

Виктор правильно уловил один важный момент и акцент. Есть предметная (логическая, методическая) архитектура, есть техническая модель реализации.

Первую как раз описывает Станислав, и, действительно, версия документа должна появляться крайне редко. Версия -- это способ зафиксировать изменение "документной единицы" во времени, так и только так. Для проекта документа это будет новая редакция между соседними правками, а также, возможно, финальный вариант документа (например, уже в виде образа). Впрочем, если, например, отсканированный образ является самостоятельным равноправным участником процесса (в задачах архивирования, например), то имеет смысл выделять его в отдельную "документную единицу". (Я тут ввел временный и довольно дурацкий термин "документная единица" - "ДЕ", чтобы уйти от сомнительного документа и от еще более сомнительного record'а, который, увы, даже Станиславом никак не переводится).

Другие варианты документа -- например, новая редакция стандарта, представление документа в другом формате для другой аудитории и т.д.  -- еще более имеет смысл оформлять самостоятельными ДЕ.

Однако есть техническая реализация, и каждая СЭД/ECM решает вопрос с версионностью в меру своей испорченности: исторической практики, ограничений архитектуры и ресурсов. Вопрос Ольги -- если копнуть -- как раз, видимо, в когнитивном диссонансе: восприятии разницы между технической и методической стороной вопроса.

И да, Станислав, спасибо за ваши комментарии и высокие требования к специалистам DIRECTUM. Будем стараться соответствовать!

Ольга Ситникова 24 января 2011 г. 10:46  
Ольга,
Станислав) Я по Вашей наводке заглянула в MoReq, в частности, в глоссарий к нему. И эта уникальная спецификация сказала мне, что версией документа считается его состояние в некоторый момент разработки.
Далее в примечании указано, что версией считается один из проектов документа или окончательный документ. В некоторых случаях, однако, законченный документ существует в нескольких версиях (например, техническое руководство). И только официальный документ не может существовать более, чем в одной версии.
В соответствии с этим я могу версиями неофициальных документов считать всё, что душе угодно, что связано с моим документом.
Ну а поскольку могу, то вопрос, который я хотела задать постом: как удобнее организовать работу? Не больше и не меньше. В частности, с визуальным контентом.
 
Пример с фотографиями Василия вообще эзотерически выносит мозг. Вы хотите сказать, что Василий в 20 лет по его содержимому (контенту) = Василий в 70 лет? Или человек в 20 лет и он же в 50 — это просто версии одного и того же субъекта.
Да, я так считаю. Даже великая спецификация MoReq даёт мне право считать Василия в 20 лет стадией разработки Василия в 70 лет. Непонятно, почему Вы сами ставите знак равенства между версиями документа, я не думаю, что версии одного документа есть одно и то же. Контент в них может быть разный.
 
Фотографии одного объекта, сделанные с разных ракурсов - абсолютно разные документы, а не версии одного и того же документа. На одной фотографии есть информация, которой нет на другой. Контент разный.
Вообще не факт. Может, это здание, одинаково выглядящее со всех сторон =))
 
ИТ-аналитик одной из лидирующих СЭД компаний не имеет права писать такое
Иногда чёткое следование стандартам порождает возникновение вокруг разума человека стен, через которые сложно увидеть, что есть другие ситуации, другие требования, жизнь хотя бы. Из этого следует ограниченность. Я верю в себя, я верю в удобство, в логику свою верю ещё. И если, когда у меня будет своя компания, мне будет казаться эффективнее все фоточки человека хранить в одном документе, так я так и буду поступать. А права свои я знаю) Например, право на свободу мысли и слова, гарантированное мне статьёю 22 Конституции РФ =)
 
Кстати, а что значит слово «какбэ»? Это новый термин?
"Это слово пишется через "е". Оно означает ровно то же, что слово "как бы", являясь сленговым вариантом этого слова." К.О.
Андрей Колесов 24 января 2011 г. 11:13  

Проблема, я уверен, лежит в понятийной основе. Точнее - в ее отсутствии. В отрасли нет достаточно понятного определения "документ". Если нет понятия документ, то как можно говорить о версиях документа.

Я написл свой комментарий в виде записи в своей блоге: http://www.pcweek.ru/ecm/blog/andrey-kolesov/580.php

Виктор Золотов 24 января 2011 г. 12:19  

Андрей, вы столь упорно пытаетесь найти всему универсальные термины...  

Оно конечно правильно, но если не выходит - ну может и не надо пока? Локальные определения подойдут?

Если у меня просто есть задача автоматизировать работу (подготовка, согласование, утверждение...) договора, то всем же ясно что такое документ? А если не ясно так ввести определения "прямого действия"? Ну например:

  • Основной договор - это документ.
  • Приложение, допник отдельным фалом - таки тоже документ ).

 

Это же разговор такой... ну немного затянувшийся. Есть определения, например "коммуникатор", "смартфон", "КПК"... И что к чему относится не разберешь. Но никто и не парится - просто вот Iphone... Всем понятно о чем речь. А что это? Ну как посмотреть ).

В нашем конкретном примере, неужели непонятно что такое документ и что такое версия? Классифицировать что-то это не так просто, тут упорство и годы Карла Линея надо ). А нам то оно надо?

Ольга Ситникова 24 января 2011 г. 12:26  

в своей блоге

Я не вводила понятия "виртуальный контент". Там было "визуальный". Исправьте, пожалуйста, свой блог)
Ольга Ситникова 24 января 2011 г. 12:43  
Не надо относиться к визуальному контенту как чему-то обособленному, иначе придется еще много чего выделять.
Почему нет? У визуального контента есть свои особенности. Но при этом совершенно необязательно плодить для него ещё сущности. Достаточно признать, что визуальный контент хочет, чтобы с ним поступали особенно, поскольку он стал неотъемлемой частью ECM, но часто его особенности упускаются.
 
Это единственное, что я хотела сказать в своём блоге. Считаю возникновение терминологических войн беспочвенным.
Станислав Ким 25 января 2011 г. 14:10  

Коллеги, здравствуйте,

Отвлекся на проведение семинара про проектированию и прототипированию программных интерфейсов, кстати тоже крайне актуальная для СЭД тема, особенно касательно проектировования и кастомизации интерфейсов СЭД под конкретную отрасль, заказчика, группу специалистов. Об этом как-нибудь отдельно поговорим.

В первых словах еще раз хотел бы извиниться за "жесткий троллинг" (по форме моих высказываний, но не содержимому) в первую очередь перед Ольгой. Я не призываю быть зашоренным и  бегать только в зоне огороженной флажками, но если вы специалист, то должны не просто задавать вопросы (такие-то фотографии - версия или не версия?), но и утверждать с какой точки зрения это версия, с какой - официальный, значимый для бизнеса документ, а с какой просто информационный материал для того же портала. Плюс изъясняться надо четче и яснее и приводить более продуманные примеры, которые будут наводить на нужные мысли, а не размывать и так зыбкие представления о СЭД-действительности. А терминологические войны будут всегда, пока отрасль бурно развивается, развитие закончится, все стандартизируется, обсуждать будет нечего.  

Всем: моя задача не просто высказать свое мнение, но и привлечь максимальное количество людей к обсуждению. Учитывая резонанс, а также появление в эфире "новых" старых специалистов, моя задача выполнена. Если при этом несколько пострадали молодые бойцы, ничего страшного, крепче будут. 

Ольга Ситникова 25 января 2011 г. 16:19  
должны не просто задавать вопросы

Станислав, Ваше мнение о том, что должны, а чего не должны делать специалисты, имеет место быть. Однако, я считаю, что не всегда вещи, как Вы написали, наводящие на "нужные мысли" - это именно то, чего хочет добиться автор статьи, поста, блога, высказывания, да чего угодно. Да и опять же вопрос: кому нужные мысли и для чего нужные?

У меня своего мнения на счёт версионности в данном конкретном случае не было. У меня были только вопросы, да в виде вот таких "непродуманных", "примитивных" примеров. Мне хотелось узнать, что делать-то в сложившихся условиях? И да, мне хотелось узнать, когда версия, а когда не версия, и версия ли вообще или может вообще это заморский грибной суп из сельдерея. Я высказала свои мысли ровно так и ровно в той степени продуманности, в которой хотела.

И да, иногда задать вопрос и оставить его без ответа - лучше для чужого мозга, чем дать ответ или его варианты непосредственно в тексте. Вы где-нибудь в ненаучной литературе видели, чтобы автор писал "а вот тут у меня героиня под поезд бросилась, потому что её совесть заела..."? Да, в научных статьях идеи-решения предлагаются, НО мой пост на научную статью не претендовал, не претендует и претендовать не будет. Он претендует на сборник вопросов в конкретной области, касающейся того, что сейчас ВООБЩЕ НЕ ПОНЯТНО, ЧТО ДЕЛАТЬ С КАРТИНКАМИ В ECM. Ваше мнение по поводу того, что это должны быть разные документы (или record-ы, по-вашему) понятно и учтено.
 
<Удалено модератором>
Виктор Золотов 25 января 2011 г. 16:38  

Ну как минимум Станислав заставил Ольгу "подумать над вопросом" ). 

Но Ольга слишком остро реагирует на критику. Мне уже жалко Станислава). И так то "был невиновен", еще и извинился (и ведь все ради Ольги!), а его снова поминают в суе... 

Критика - то что нас учит. Критика в целом, если конструктивна - в любом виде полезна. Публичная кстати - тем более.

Так что привыкайте, Ольга. Будете писать в публичном блоге, будет получать комментарии в сравнении с котором скромный и порядочный представитель культурной столицы вспомнится вам как трогательный момент столь быстро прошедших дней.

 

Елена Питомцева 26 января 2011 г. 08:45  

Спасибо всем за интересную дискуссию. Надеюсь, все смогут найти полезное для себя в этом споре, оставив в стороне эмоции.

Сейчас обсуждают
Евгений Кочуров 20 марта 2017 г. 07:49  
Юрий Зерин 18 марта 2017 г. 19:18  
Сергей Бушмелев 15 марта 2017 г. 22:47  
Елена Истомина 15 марта 2017 г. 13:08  
Сергей Бушмелев 15 марта 2017 г. 10:46  
Больше комментариев