loadXML,load(uri),load(dom) sync or async ?

This post is to clarify some of my statements presented in webreflection blog comments (do not want to waste your space Andrea).

"Official Documentation" (more cookbook than API specification)

• boolValue = oXMLDOMDocument.loadXML(bstrXML);
  
• boolValue = oXMLDOMDocument.load(xmlSource);
  
• oXMLDOMDocument.async
  

Question: is it guaranteed by "specification" that dom.loadXML is blocking regardless on dom.async property ? Do I have to write dom.async=false to perform intentional synchronous load of xml string ?

(not)Final Note

Since I have failed to "clearly" decrypt the documentation wording to come up with presentable argument I provide tests: Experiments show that current implementation of MSXML (all tested versions) show:

• async=false - load(uri) - IS BLOCKING
  
• async=true - load(uri) - IS NONBLOCKING
  
• async=true - load(dom) - IS BLOCKING (logical ?, documented ?)
  
• async=true - loadXML(string) - IS BLOCKING (logical ?, documented ?)
  

Usage of onreadystatechange is available in both async, and sync modes.
Would you write different code for load(uri) and load(dom/stream) ?
I do not.


For intentionaly synchronous code I will write async=false before any load (loadXml/load(dom)/load(uri))
and will continue processing after load exits (even if "runtime behavior" shows async=false as unnecesary for loadXml/load(dom)).


For intentionaly asynchronous code I will write async=true before any load (loadXml/load(dom)/load(uri))
(even if it's default) and will use readystatechange, and will not rely on load blocking (even if "runtime behavior" show that loadXml/load(dom) blocks).

Argument that loading string cannot be asynchronous is naive, anything can be made asynchronous even i++ if component designer decides to be and language + runtime features alow that ;-)