real time - tipos - ¿La transformación operativa funciona en documentos estructurados como HTML si se trata simplemente como texto simple?
que es una etiqueta html (3)
Hay enfoques en OT que admiten SGML (superconjunto de XML), pero no hay implementaciones. Por lo tanto, no es imposible! Aunque, estoy de acuerdo, OT no es el mejor enfoque para habilitar XML. Esto se debe a que OT fue diseñado para estructuras de datos lineales. Pero HTML / XML es mucho más complejo: tiene atributos y está construido como un árbol. El hecho de que sea un árbol es solucionable, pero los atributos, que se realizan como una matriz asociativa ordenada, no son compatibles con OT. Simplemente porque las matrices asociativas no son compatibles con OT (en este momento). El enfoque anterior en realidad recomienda tratar los atributos como una cadena: por ejemplo, "id = ''myid'' value = ''mystuff''", pero puede romper fácilmente la sintaxis completa de su ''cadena de atributos'', cuando un usuario elimina todos los atributos, y otra inserta un "carácter directamente después de" mystuff ". Esto podría resolverse en una etiqueta div que se parece a esto <div "> , que no es una sintaxis válida.
Tal vez esto te interese:
CEFX es un proyecto que apunta a soportar XML, está muerto, que yo sepa. Pero utiliza un enfoque OT. Por alguna razón, no es posible editar cadenas, solo elementos xml.
Drive SDK de Google admite estructuras de datos similares a gráficos. Es, sin embargo, propietario y nadie sabe cómo funciona.
Estoy desarrollando un marco que soporta estructuras de datos arbitrarias. Actualmente, se admiten texto, Json, XML y HTML. Tiene un enfoque diferente: échale un vistazo: Yatta!
BTW: Lo que el protocolo Wave y Eric Drechsel describieron se conoce como Annotations in OT. Es comúnmente aprovechado para soportar texto enriquecido.
La sección de preguntas frecuentes de Google Wave Protocol dice que [HTML] "no tiene propiedades deseables" y que "HTML hace que las OT (Transformaciones operativas) sean difíciles, si no imposibles" [1]. ¿Por qué esto es tan? ¿Qué problemas surgen si el HTML se trata simplemente como texto simple y luego se aplica OT?
No tengo una respuesta completa, pero me interesa ver que se haga más trabajo para hacer que las bibliotecas de transformación operativa de código abierto existentes funcionen con texto enriquecido, así que contribuiré con lo que sé.
La diferencia importante entre HTML y el esquema de Wave parece ser la forma en que se marca el formato del texto: una jerarquía de etiquetas anidadas para las anotaciones de HTML frente a fuera de banda (en el pie de página del documento) con rangos para Wave XML. Las anotaciones fuera de banda son probablemente una forma más natural de marcar el formato del texto, ya que permiten la superposición de formatos (no anidados). Permite algo como esto (en pseudomarcado), que no sería un XML válido usando la representación anidada:
(b) This is bold (i) while this range is both bold and italic (/b) and this last bit is just italic (/i)
Relacionado, aquí está el tema relevante en el proyecto ShareJS . Tal vez puedan implementar el soporte de texto enriquecido mediante la adopción de parte del esquema XML de Wave.
Supongo que aquí entiendes los conceptos básicos de OT. El principal problema con hacer OT en HTML como texto sin formato es el de fusionar etiquetas html. Como un simple ejemplo, digamos que tenemos un documento de la siguiente manera:
Hello world
Entonces, Alice decide que el mundo debería estar en negrita:
Hello <b>world</b>
Esto se puede representar con una operación de inserción doble en OT, esquemáticamente:
Edit A: Keep 6 : Insert "<b>" : Keep 5 : Insert "</b>"
Si Bob decidiera que ''mundo'' debería estar en cursiva antes de ver la edición de Alice, agregaría la operación
Edit B: Keep 6 : Insert "<i>" : Keep 5 : Insert "</i>"
Si el servidor recibió la edición de Bob después de la de Alice, tendría que transformar B en A para convertirse en B ''.
Las declaraciones de Mantener no han cambiado a través de la transformación, pero Insertar "" transformado sobre Insertar "" puede convertirse en Mantener 3: Insertar "" o Insertar "": Mantener 3. Generalmente, el servidor se configurará para colocar la edición posterior después de la primera edición.
Edit B'': Keep 6 : Keep 3 : Insert "<i>" : Keep 5 : Keep 3 : Insert "</i>"
Aquí el problema se vuelve obvio. Al aplicar A y luego B ''a la cadena original, se obtiene el html no válido:
Hello <b><i>world</b></i>
Teóricamente, esto podría resolverse variando las inserciones previas y posteriores, pero se vería afectado por ejemplos más complicados, lo que podría implicar un escaneo completo del documento para cada transformación.
Como se señaló en la otra respuesta, este desorden puede evitarse usando anotaciones fuera de banda + texto sin formato. Otro enfoque que solo he visto hasta ahora en documentos académicos es tratar la estructura XML como un árbol con operaciones OT para la adición, eliminación de nodos, por ejemplo:
http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.100.74