#raw as outputType

Hi David, #raw really comes in to play when your returning XML from your mashup. For e.g if I was to return "my value" instead of "my value" the response would be "my value", no wrapping at all. As of now we do not allow returning plain text from a mashup. But we could add this feature. Could you log a JIRA requesting for this feature. A workaround for you would be to wrap the data returned using a dummy XML tag and then get rid of it at the processing side. As for your second question you could use system.getXML(url) to perform a simple GET. This would return the response as XML. Thanks, Keith. Blog: http://www.keith-chapman.org/

Keith is correct. I think of "#raw" as _raw xml_, as opposed to rpc-wrapped xml which you get from the value "xml". The automatic wrapping of non-xml values into an XML package is part of the tricky boundry between static and dynamic languages. When you declare the return type to be raw xml, but give us something that's not xml, we convert the value if possible - in this case by wrapping the string in XML and annotating it's original type. Try this instead: return <response>my value</response>; And also try the above with outputType="xml" to see the difference in the payload. I'd be interested to know what your requirements are for non-XML media type returns.

Hi Keith, I am actually trying to return XML (an XSL document), and my problem was it was wrapping it with the additional XML and I did not feel like doing additional processing to extract the stylesheet, and thought this was a problem with the mashup server. However, the data service I was pulling this stylesheet was getting it as text and returning it as a string, so I simply just needed to issue a 'return new XML(document);' and it worked like a charm. Thanks so much, David

Hi Jon, See my reply to Keith. I had actuallly just simplified the example to see if my understanding of it was clear. However, I didn't know that raw stood for raw_xml, I just thought it meant 'dont mess with my response'. I did, however, want an XML response. Just wanted one that was untouched by the Mashup Server. I tested returning an E4X and received the desired results :) Thanks, David

Hi again... Whenever I pass XML to a mashup procedure that expects XML as the input type, it throws an exception if <?xml version="1.0"?> or an equivalent type tag is included in the XML document. Why is this? I am always having to strip out the XML header to make use of the methods. Isn't it bad practice to exclude this from your documents, or is this becoming a standard? I fear that someone using our services is going to include this header just because its so common and the service will not work as expected, even though, to the end user, its perfectly valid XML. Thanks, David

There are some scenarios where the xml declaration causes some headaches. Let me enumerate them. I believe it is best practice to indeed include the XML processing instruction in files, including those POSTed to an HTTP binding endpoint. If this isn't working I would consider this a bug. Within the mashup, E4X has a very unfortunate property - that when parsing an XML document using new XML(), it does not expect to encounter an xml declaration. It thinks it's a regular processing instruction, which is prohibited by the XML spec from using the name "xml". This appears to be part of the E4X standard, so changing the behavior is a bit nasty, as we have to trade off between _right_ behavior and a _compliant_ behavior. You can encounter this when you load a file (using the File object), or when you get some XML back from the Scraper object (e.g. html-to-xml). system.getXML() should be immune to this effect. The workarounds are either to strip off the XML declaration: var r = new XML(scrape.response.substring(scrape.response.indexOf("?>") + 2))); (which expects that there always will be an xml decl) or you can sometimes eliminate it in the source, e.g. in a scrape use xslt with <xsl:output omit-xml-decl="yes"/>. I agree this is a royal pain, and we have a feature request in place to get XML back directly from the Scraper object (so we don't have to reparse and potentially hit the decl at all). We could also provide an option to strip this off of any text that is returned from the Scraper or File object. But the root of the problem lies in the E4X behavior, and maybe we'll just have to consider a patch to new XML() that silently eats xml "processing instructions" when they appear at the start of a text stream.