4 Replies Latest reply on Sep 6, 2007 7:54 AM by Grizzly9279

    XMLParse mislead by XSI/XMLNS/schemaLocation?

    Castaway77
      I seem to have a problem with XMLParse and the XSI bits of my XML in myt code below.

      When I take out these 3 lines

      xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"
      xmlns=" http://www.opentravel.org/OTA/2003/05"
      xsi:schemaLocation=" http://www.opentravel.org/OTA/2003/05 OTA_DestActivityResRQ.xsd"

      the code does what I expect it to do. I get a struct with four name value pairs.

      But when the lines are in (as they should be as per the OTA spec) the struct is of zero length. It seems XMLParse is being confused in some way by these lines.

      I have no idea what the problem is? Any XML gurus out there got a clue? I realize I could kludge a solution by blatting the offending lines from the incoming XML before parsing it but I would like understand what in the 3 lines is causing the problem.

      Regards,

      Sean



        • 1. XMLParse mislead by XSI/XMLNS/schemaLocation?
          Grizzly9279 Level 1
          You've stumbled upon a long-standing "known issue" that has plagued CF's xmlSearch function for a long time now. Often times nested namespaces in XML documents cause xmlSearch to fail (or not match).

          To get around this, we often just use a quick regex replace statement to trim out name spaces from the entire xml string (before calling xml-parse).

          Example:
          <cfset xmlResponse = reReplace( xmlResponse, '[ ]*xmlns=\"[^\"]*\"', "", "all" )>

          Hopefully this will work for you. It's a "hack" I know, but it's the only viable work-around I've heard of.
          • 2. Re: XMLParse mislead by XSI/XMLNS/schemaLocation?
            Castaway77 Level 1
            Thanks for that Grizzly9279.

            Problem solved.

            Regards,

            Sean
            • 3. Re: XMLParse mislead by XSI/XMLNS/schemaLocation?
              david.collie
              Removing all namespaces could have detrimental effects later on in your logic.

              Since there is more than one namespace in the XML document you supplied, you must qualify all elements when performing an XMLSearch with their namespace, even if it is the default.

              Original:
              "/OTA_DestActivityResRQ/DestActivityReservation/DestActivityItems/Item/@ItemCode"

              Modified:
              "/:OTA_DestActivityResRQ/:DestActivityReservation/:DestActivityItems/:Item/@ItemCode"

              Please note the colon in the example above to indicate that the element searched upon is in the default namspace.

              The code supplied now returns a structure with 4 keys as expected when applying the modified XPath expression.
              • 4. XMLParse mislead by XSI/XMLNS/schemaLocation?
                Grizzly9279 Level 1
                A very good point cf_eilloc. That approach works fine when you're dealing with only one namespace (such was the case here), but when you encounter nested namespaces (2 or more deep), you're pretty much screwed and are forced to strip them all out if you want to search the document.

                So in general practice, I prefer to simply strip out namespaces altogether unless there is a specific need or purpose of including them in my search.