>>Unfortunately, this provides the same result.
>
>Could you post the resulting documents, one just after the ENDSCAN and the other as it is returned by STRCONV()?

Unfortunately not, the content in regards to that is presently confidential.

I am trying a direct DOM maniapulation. I thought for a while that avoiding creating an additional object as a wrapper for the DOM object could have made it to work as it seems the entire concept was working better. However, as I was about to say Bingo!, I just found that it is not technically working accurately as well.

The more content I keep adding to the XML string, the less it'll work. But, it's not specific to a specific content length. For example, one of my field is string equivalent of an integer. If I replace that with a GUID value, it'll fail. However, if I keep the string equivalent of an integer, and add more fields, it'll work. However, if I add too much fields, it won't work.

Presently, I have something like this:

* Create the object
loXML=CREATEOBJECT('MSXML.DOMDocument')

* Create the root
loNode=loXML.CreateElement('ContentItemList')
loXML.DocumentElement=loNode

SCAN

   * Add a record
   loRecord=loXML.CreateElement('ContentItem')
   loNode.AppendChild(loRecord)

   * Add the GUID
   loGUID=loXML.CreateElement('GUID')
   loRecord.AppendChild(loGUID)
   loGUID.NodeTypedValue=ALLTRIM(STR(Numero)) &&GetGUID()

   * Create the keywords
   loKeyword=loXML.CreateElement('Keywords')
   loRecord.AppendChild(loKeyword)

   ...
ENDSCAN

loXML.Save('d:\a.xml')
RETURN FILETOSTR('d:\a.xml')

So, as you can see, from the XML build level, I no longer have the STRCONV() as the XML DOM object Save() method will do it properly. However, the Web Service will still choke on the STRCONV() line.