Sollte DOM splitText und normalize komponieren, um die Identität zu geben?

Question

Ich wurde gestern in eine Diskussion über DOM-Implementierungsquirks verwickelt, was zu einer interessanten Frage bezüglich des Verhaltens von Text.splitText und Element.normalise führte und wie sie sich verhalten sollten.

In DOM Level 1 Core wird Text.splitText as ...

definiert

Pausen dieser Text Knoten in zwei Knoten Text an den Offset bestimmt ist, sowohl in der Struktur als Geschwister zu halten. Dieser Knoten enthält dann nur den gesamten Inhalt bis zum Offsetpunkt. Und ein neuer Text-Knoten, der als das nächste Geschwister dieses Knotens eingefügt wird, enthält den gesamten Inhalt an und nach dem Offset-Punkt.

Normalisieren ist ...

Wandelt alle Textknoten in der vollen Tiefe der Unterbaum unterhalb dieses Element in eine „normale“ Form, wo nur Markup (zB Tags, Kommentare, Verarbeitung Anweisungen, CDATA-Abschnitte und Entitätsreferenzen) trennt Textknoten, dh es gibt keine benachbarten Textknoten. Dies kann verwendet werden, um sicherzustellen, dass die DOM-Ansicht eines Dokuments dieselbe ist, als wäre sie gespeichert und erneut geladen worden. Dies ist nützlich, wenn Operationen (wie XPointer-Lookups) verwendet werden sollen, die von einer bestimmten Dokumentbaumstruktur abhängen.

Also, wenn ich einen Textknoten mit „Hallo Welt“ nehmen, in textNode Bezug genommen wird, und tue

textNode.splitText(3) 

textNode hat jetzt den Inhalt „Hallo“ und ein neues Geschwisterkind mit „World“

Wenn ich dann

textNode.parent.normalize() 

was textNode ist? Die Spezifikation macht es nicht klar, dass textNode immer noch ein Kind seines vorherigen Elternteils sein muss, nur aktualisiert, um alle benachbarten Textknoten zu enthalten (die dann entfernt werden). Es scheint ein Konformationsverhalten zu sein, alle angrenzenden Textknoten zu entfernen und dann einen neuen Knoten mit der Verkettung der Werte neu zu erstellen, wobei textNode auf etwas verweist, das nicht mehr Teil der Struktur ist. Oder wir können textNode auf die gleiche Weise wie in splitText aktualisieren, so dass es seine Baumposition beibehält und einen neuen Wert erhält. Die Wahl des Verhaltens ist wirklich ganz anders, und ich kann keine Klärung finden, welche richtig ist, oder ob dies einfach ein Versehen in der Spezifikation ist (es scheint nicht in den Ebenen 2 oder 3 geklärt zu sein)). Können irgendwelche DOM/XML-Gurus etwas Licht ins Dunkel bringen?

Answer 1

Ich war in den frühen Tagen auf der DOM Working Group; Ich bin sicher, dass wir bedeuten für textNode den neuen verbundenen Wert zu enthalten, aber wenn wir nicht sagen taten es in der Spezifikation, ist es möglich, dass einig Implementierung könnte einen neuen Knoten erstellen, anstatt textNode der Wiederverwendung, obwohl das mehr Arbeit für die Implementoren erfordern würde.

Im Zweifelsfall defensiv programmieren.

Answer 2

Obwohl es eine vernünftige Annahme zu sein scheint, stimme ich zu, dass es in der Spezifikation nicht explizit gemacht wird. Alles, was ich hinzufügen kann, ist, dass die Art, wie ich es lese, entweder textNode oder sein neues Geschwister (dh Rückgabewert von splitText) würde den neuen verbundenen Wert enthalten - die Anweisung gibt an, dass alle Knoten im Unterbaum eingefügt werden Normalform, nicht dass der Unterbaum auf eine neue Struktur normiert ist. Ich denke, die einzige sichere Sache ist, einen Bezug auf den Elternteil zu halten, bevor man normalisiert.

Answer 3

Ich denke, alle Wetten sind hier weg; Ich würde sicherlich nicht von einem bestimmten Verhalten abhängig sein. Die einzige sichere Sache ist, den Knoten wieder von seinem Elternknoten zu bekommen.