handling non-html documents
qMax
а проблема заключается в моём недопонимани возможностей API.
суть задачи в том, что в волну предполагается поместить xml-документ,
котрый нифига не html.
и этот докумет должен рендериться и редактроваться особым образом.
например - документ представляет из себя онтологию в формате OWL/RDF,
и должен изображаться в виде семантического графа, с возможностью
добавления новых узлов.
на первый взгляд, это задача гаджета.
однако, гаджеты оперируют только своим состоянием, котрым является
словарь сопоставления строк.
(вопреки тому, что говорится в презентациях, где состояние гаджета
объявляется XML-документом)
таким образом документ нельзя поместить как состояние гаджета.
кроме того, у гаджета нет обработчиков изменения контента волны.
прнимая во внимание последний момент, можно сделать вывод, что под
такую задачу надо создать робота.
при этом весь контент документа должен храниться гдето вне волны,
а бот будет генерить по нему html-представление и пихать его в волну.
это должно сработать,
но выглядит совершенно коряво и совершенно не по-волновски.
как быть ?
Dmitry Unkovsky
> суть задачи в том, что в волну предполагается поместить xml-документ,
> котрый нифига не html.
> и этот докумет должен рендериться и редактроваться особым образом.
Мне близки вопросы, затрагиваемые вами ;)
Я думаю, речь может идти о расширении правил OT для других типов данных.
И, соответственно, о расширенном клиенте/сервере.
--
DU
qMax
операции elementStart, elementEnd, deleteElementStart,
deleteElementEnd применимы к любому XML.
On Aug 16, 7:50 am, Dmitry Unkovsky <oil.cray...@gmail.com> wrote:
> 2009/8/15 qMax <qwigly...@gmail.com>:
Dmitry Unkovsky
Hash: SHA1
2009/8/16 qMax :
> правила OT никак не пирвязаны к html.
> операции elementStart, elementEnd, deleteElementStart,
> deleteElementEnd применимы к любому XML.
>
На мой взгляд, дело не только в том, применимы или нет.
Бесспорно, что любую структуру данных компьютера известной архитектуры
можно так или иначе представить в виде xml.
Вопрос в другом, насколько адекватно определенные в OT операции будут
представлять пользовательские операции со специфическим типом данных.
Тривиальным примером тому может быть операция "увеличить счетчик".
В рамках существующих операций эквивалента ей нет.
Другим примером будет, возможно, операция "переместить поддерево к
другому родителю".
Ясно, что, скажем, правки пользователя, редактирующего один из узлов
поддерева, не будут конфликтовать с такой операцией, в то время как
они, конечно, конфликтуют с двумя правками delete,insert, так что
врезультате стандартного разрешения конфликта одна из правок будет
утеряна.
Еще один пример -- упорядоченный список, с операцими перемещения элементов.
То же касается многих других специфических типов данных.
Правила OT определяют набор операций и адекватные способы разрешения
конфликтов при совместном редактировании.
Думаю, эта тема актуальна и в применении к семантической сети, и к
пространству вариантов некоторого документа.
- --
DU
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkqHdAIACgkQqdN5Ji6Vwmf+MQCaAl4AIxeoqxHWTb+H2/VwMmue
zGsAnRBYrKDKOX7b7do3jZajh0p1w7sr
=7F2N
-----END PGP SIGNATURE-----
Ilya Nenashev
Но при этом содержать и того и другого много — про целый переводимый документ во всех его ипостасях? В принципе, тогда у движка этого гаджета будет вся информация для его работы...
в google-wave-api тему (пока) не пропускают модераторы.
а проблема заключается в моём недопонимани возможностей API.
суть задачи в том, что в волну предполагается поместить xml-документ,
котрый нифига не html.
и этот докумет должен рендериться и редактроваться особым образом.
например — документ представляет из себя онтологию в формате OWL/RDF,
и должен изображаться в виде семантического графа, с возможностью
добавления новых узлов.
на первый взгляд, это задача гаджета.
однако, гаджеты оперируют только своим состоянием, котрым является
словарь сопоставления строк.
(вопреки тому, что говорится в презентациях, где состояние гаджета
объявляется XML-документом)
таким образом документ нельзя поместить как состояние гаджета.
кроме того, у гаджета нет обработчиков изменения контента волны.
прнимая во внимание последний момент, можно сделать вывод, что под
такую задачу надо создать робота.
при этом весь контент документа должен храниться гдето вне волны,
а бот будет генерить по нему html-представление и пихать его в волну.
это должно сработать,
но выглядит совершенно коряво и совершенно не по-волновски.
как быть ?
-~-~---~-~--~----~---~-~--~
Данное сообщение отправлено Вам, так как Вы являетесь подписчиком
группы «Google Wave Россия» в Группах Google.
Для того, чтобы отправить сообщение в эту группу, пошлите его по адресу
google-wa...@googlegroups.com
Чтобы отменить подписку на эту группу, отправьте сообщение по адресу:
google-wave-rus...@googlegroups.com
Чтобы выполнить другие действия, посетите страницу группы
http://groups.google.com/group/google-wave-russia?hl=ru
-~----~--~--~--~---~--~--~-~-
qMax
Ну в этом смысле ОТ вообще никаким боком к XML-операциям не применима.
По крайней мере в той форме, как она описана в презентациях и
документах.
qMax
он видит и реагирует только на собственное состояние.
такчто тут как ни крути, а придётся делать робота.
а вот хранить структурированный документ в отдельном блипе или лучше
вэйвлете - это да.
только не совсем понятно, как его скрыть ото всех, кроме робота...
и ещё совершенно непонятно каким API вставлять фишки типа подсказок
Спелли.
On Aug 16, 2:03 pm, Ilya Nenashev <innenas...@gmail.com> wrote:
> А если гаджет будет типа блипа -- содержать и видимый редактируемый HTML,
> и служебный XML?
> Но при этом содержать и того и другого много -- про целый переводимый