Bad XML from MS/Exchange 2000?

[Scott Sanders <sa...@totalsync.com>]

I am posting this question to the Xerces dev list to ask the gurus that I
know of if they can help...

I am using the jakarta-slide client library to talk WebDAV to Exchange
2000/IIS 5.0 on Windows 2000 Server.  I have successfully updated properties
and so on, so I decided to implement a SEARCH method for the Slide client
library.  I send an HTTP request, expect an XML response in return, so that
I can parse it for the information that I care about.  In doing so, I am
sending a request to IIS that looks something like this:

  SEARCH /exchange/scott/Calendar/ HTTP/1.1
  Content-Length: 128
  Content-Type: text/xml; charset=utf-8
  host: localhost
  user-agent: org.apache.webdav.lib.WebdavClient


  <?xml version="1.0" encoding="utf-8" ?>
  <D:searchrequest xmlns:D="DAV:">
    <D:sql>
  SELECT * FROM
    </D:sql>
  </D:searchrequest>

And the response was:

  HTTP/1.1 207 Multi-Status
  Server: Microsoft-IIS/5.0
  Date: Wed, 10 Jan 2001 23:51:55 GMT
  Content-Type: text/xml
  Accept-Ranges: rows
  Transfer-Encoding: chunked

The response content is attached as a file.  When I open the file in any
Windows program that uses Microsoft's XML parser (XML Spy, IE5.5, etc), the
file is well-formed and parses correctly.  When I try to parse the file with
a Java-based parser, including Xerces 1.2.3, I get an error.  I have tried
Xerces, Crimson, and Saxon's Aelfred parser.  The error I get from Xerces
is:

org.xml.sax.SAXParseException: An invalid second ':' was found in the
element type or attribute name.
 at org.apache.xerces.framework.XMLParser.reportError(XMLParser.java:1008)
 at
org.apache.xerces.framework.XMLDocumentScanner.scanElementType(XMLDocumentSc
anner.java:2063)
 at
org.apache.xerces.framework.XMLDocumentScanner.access$1(XMLDocumentScanner.j
ava:2052)
 at
org.apache.xerces.framework.XMLDocumentScanner$ContentDispatcher.dispatch(XM
LDocumentScanner.java:1219)
 at
org.apache.xerces.framework.XMLDocumentScanner.parseSome(XMLDocumentScanner.
java:380)
 at org.apache.xerces.framework.XMLParser.parse(XMLParser.java:900)
 at
org.apache.xerces.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:12
3)
 at
org.apache.webdav.lib.methods.XMLResponseMethodBase.parseXMLResponse(XMLResp
onseMethodBase.java:221)
 at
org.apache.webdav.lib.methods.XMLResponseMethodBase.parseResponse(XMLRespons
eMethodBase.java:199)
 at org.apache.webdav.lib.WebdavClient.executeMethod(WebdavClient.java:338)
 at org.apache.webdav.cmd.Main.processCommands(Main.java:237)
 at org.apache.webdav.cmd.Main.access$0(Main.java:88)
 at org.apache.webdav.cmd.Main$1.run(Main.java:158)
 at java.lang.Thread.run(Thread.java:484)

The problem line (according to a JDOM sample using xerces) is (located at
line 48 in the attached file):
  <k:0x001A001F>IPM.Appointment</k:0x001A001F>

This line is the Microsoft MAPI Classname property, in case you were
wondering.



So, I go out to http://www.w3.org/TR/REC-xml, and read the XML spec.  It
says:

[39]   element   ::=   EmptyElemTag | STag content ETag
[40]   STag   ::=   '<' Name (S Attribute)* S? '>'
[4]   NameChar   ::=   Letter | Digit | '.' | '-' | '_' | ':' |
CombiningChar | Extender
[5]   Name   ::=   (Letter | '_' | ':') (NameChar)*

So, basically the XML spec says it is OK.  So I go and check out the
Namespaces spec:

[6] QName::= (Prefix ':')? LocalPart
[7] Prefix::= NCName
[8] LocalPart::= NCName
[4] NCName::= (Letter | '_') (NCNameChar)*/* An XML Name, minus the ":" */
[5] NCNameChar::= Letter | Digit | '.' | '-' | '_' | CombiningChar |
Extender

So, according to the Namespaces spec, it is invalid XML.  Which one is
authoritative in this matter?  Anyone with any suggestions on how to pursue
this further?  I do fully suspect that MS is wrong here, as I just got past
the invalid cookies that they are sending as well.

Thanks for your help,
Scott Sanders

Re: Bad XML from MS/Exchange 2000?

[Arnaud Le Hors <le...@us.ibm.com>]

The answer is: it depends on your parser settings. If namespaces are on,
then it's invalid. If they are off, then it's not.
-- 
Arnaud  Le Hors - IBM Cupertino, XML Strategy Group