1. Adding xml to an XMLList also does the equivalent of: XMLList[index-1].parent.insertChildAfter( XMLList[index-1]).

  2. Removing objects from the XML which is used to create an XMLList does NOT change the objects in the XML.

  3. If you have two XMLLists which reference the same structure in an XML object, changing one DOES NOT change the other.

  4. XML.attribute(“foo”) returns a weird XML object which just has the value of the specified key. Using parent() on that object does return the full XML object which the attribute belongs to.

  5. I’m not sure how to get “comment” or “processing-instruction” nodeKinds. Some quick tests did not return anything for those. I’d like to get some test cases to see how those behave.

  6. xml.*.(@name=="fred") causes an error if any xml elements do not have the attribute set, but xml.*.(attribute("name")=="fred") will work even if some nodes do not have the attribute.

  7. A convenient way to get all nodes which have a specific attribute defined (where the attribute key is "name") is this: newList = xmlList.(attribute("name").length());

  8. For complex XML which have children elements, toString() and toXMLString() give the same results. This is true even if there are text nodes as well. For example <p>I am <b>very</b> tired!</p> would return the full xml including the p tag using both methods, but <p>I am very tired!</p> would have different results. For XML which does not have child nodes, toString() returns the text or an empty string, while toXMLString() returns the full xml of the node.
  9.  hasOwnProperty("element") and hasOwnProperty("@attribute") are both valid checks for XML objects.
  10. Qualified elements can be checked using hasOwnProperty(QName).
  11. CDATA sections are parsed as Text nodes with the CDATA tags included in the text.
  • No labels