18

Najczęstsze pytania protokołu Google Wave mówią, że [HTML] "nie ma pożądanych właściwości" i że "HTML sprawia, że ​​OT (Operational Transforms) jest trudny, jeśli nie niemożliwy" [1]. Dlaczego tak jest? Jakie problemy powstają, gdy HTML traktowany jest po prostu jako zwykły tekst, a następnie OT jest stosowany?Czy transformacja operacyjna działa na dokumentach strukturalnych, takich jak HTML, jeśli traktuje się je po prostu jako zwykły tekst?

  1. http://www.waveprotocol.org/faq#TOC-What-s-the-XML-schema-for-waves-Why

Odpowiedz

5

nie mam pełnej odpowiedzi, ale jestem ciekaw więcej pracy na uczynienie istniejących bibliotek transformacji operacyjnych open source praca z tekstem sformatowanym, więc będę co przyczyni się Wiem.

Istotna różnica między schematem HTML a Wave wydaje się być taka, jak zostało zaznaczone formatowanie tekstu: heirarchia zagnieżdżonych tagów dla HTML i adnotacje poza pasmem (w stopce dokumentu) z zakresami dla Wave XML . Adnotacje spoza pasma są prawdopodobnie bardziej naturalnym sposobem oznaczania formatowania tekstu, ponieważ umożliwiają nakładanie się (bez zagnieżdżania) formatów. Pozwala ona mniej więcej tak (w pseudo-znaczników), które nie byłyby ważne XML za pomocą zagnieżdżonych reprezentacji:

(b) This is bold (i) while this range is both bold and italic (/b) and this last bit is just italic (/i)

pokrewnych, jest tu relevant issue w projekcie ShareJS. Być może mogą wdrożyć obsługę tekstu sformatowanego, przyjmując część schematu Wave XML.

+1

+1 dla [dyskusji na temat ShareJS] (https://github.com/josephg/ShareJS/issues/1)! – mb21

16

Zakładam, że rozumiesz podstawy OT. Głównym problemem związanym z wykonywaniem OT w HTMLu jako zwykłym tekstem jest scalanie znaczników html. Jako prosty przykład, że mieliśmy dokumentu w następujący sposób:

Hello world 

Alice następnie decyduje, że świat powinien być pogrubione:

Hello <b>world</b> 

To może być reprezentowany z podwójnym pracy wkładanej w OT, schematycznie :

Edit A: Keep 6 : Insert "<b>" : Keep 5 : Insert "</b>" 

Jeśli Bob zdecydował, że „świat” powinien być pochylony przed widział zmienił Alicji, że byłoby dodać operację

Edit B: Keep 6 : Insert "<i>" : Keep 5 : Insert "</i>" 

Jeśli serwer otrzymał edycję Boba po Alice, musiałby przekształcić B na A, aby stać się B '.

Instrukcje Keep są niezmienione przez transformację, ale "" Wstawione "" Przekształcone przez Insert "" może stać się "Zachowaj 3: Wstaw" "lub Wstaw" ": Zachowaj 3. Zwykle serwer zostanie skonfigurowany do umieszczenia późniejszej edycji po pierwsza edycja.

Edit B': Keep 6 : Keep 3 : Insert "<i>" : Keep 5 : Keep 3 : Insert "</i>" 

Tutaj problem staje się oczywisty. Stosując A, to B”do oryginalnego łańcucha daje nieprawidłowy HTML:

Hello <b><i>world</b></i> 

Teoretycznie to może być rozwiązany przez zmianę pre i post wkładki, ale dostanie owłosione dla bardziej skomplikowanych przykładów, potencjalnie obejmujące pełne skanowanie dokumentu dla każda transformacja.

Jak zaznaczono w innej odpowiedzi, można uniknąć tego bałaganu za pomocą adnotacji poza pasmem + zwykły tekst.Innym podejściem Widziałem tylko tak daleko w pracach naukowych jest traktowanie strukturę XML jako drzewo z operacjami OT do dodawania, usuwania węzłów, np

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.100.74

+1

Domyślam się, że podstawową kwestią jest to, że przy jednoczesnych wstawkach wynik końcowy zawsze może być semantycznie niepoprawny - ale w przypadku XML/HTML wynik końcowy może być niepoprawny pod względem składniowym. Użycie adnotacji nie eliminuje niespójności semantycznej, ale zapewnia, że ​​transformacja da prawidłowy XML/HTML i jako taka może być zawsze ładnie renderowana. Dzięki. – Nakedible

+0

Absolutnie w prawo – jazmit

1

Istnieje approaches in OT które obsługują SGML (nadzbiór XML), ale nie ma żadnych implementacji. Dlatego nie jest to niemożliwe! Chociaż, zgadzam się, OT nie jest najlepszym sposobem na włączenie XML. Jest tak dlatego, że OT został zaprojektowany dla liniowych struktur danych. Ale HTML/XML jest znacznie bardziej złożony: ma atrybuty i jest zbudowany jak drzewo. Fakt, że jest to drzewo, można rozwiązać, ale atrybuty - które są realizowane jako uporządkowana tablica asocjacyjna - nie są obsługiwane przez OT. Po prostu dlatego, że tablice asocjacyjne nie są obsługiwane przez OT (w tej chwili). Powyższe podejście zaleca traktowanie atrybutów w postaci ciągu znaków: E.g. "id =" myid "value = 'mystuff'" Ale możesz łatwo złamać całą składnię swojego "ciągu atrybutów", gdy jeden użytkownik usunie wszystkie atrybuty, a drugi wstawi "znak bezpośrednio po" móżdżku ". . Może rozwiązać w jakiś znacznik div, który wygląda tak <div ">, co nie jest prawidłowa składnia

Może interesuje cię:

CEFX to projekt, który ma na celu wspieranie XML - jest martwy do mojej wiedzy, ale używa. Z jakiegoś powodu nie można edytować ciągów - tylko elementy xml.

Dysk Google Drive SDK obsługuje struktury danych podobne do wykresów, ale jest zastrzeżony i nobodowy wie, jak to działa.

Opracowuję framework obsługujący dowolne struktury danych. Obecnie obsługiwane są: Text, Json, XML i HTML. Ma inne podejście: sprawdź to: Yatta!

Przy okazji: Co opisuje protokół Wave, a Eric Drechsel nazywa się Adnotacjami w OT. Jest powszechnie wykorzystywany do obsługi bogatego tekstu.

Powiązane problemy