Hi guys,
I'm trying to track down precisely where Xindice is setting invalid attribute namespace URIs for unprefixed attributes. According to the namespace rec, unprefixed attributes are *not* in the default namespace - hence their namespace URI should be the empty string. In both the SAX and DOM representations I'm getting back from Xindice (DarkHorse), unprefixed attributes have the same namespace URI as the default namespace.
For example, of you retrieve the following document from Xindice:
<xsl:stylesheet xmlns="http://www.w3.org/1999/xhtml"; xmlns:xsl="http://www.w3.org/1999/XSL/Transform"; version="1.0">
...
</xsl:stylesheet>
The namespace URI of the 'version' attribute will be 'http://www.w3.org/1999/xhtml', rather than ''. This holds true for accessing the doc via both the DOM and SAX.
This is a blocker for me as it means Xalan refuses to recognise the above XSLT stylesheet as being valid - it rightly complains that there is no 'version' attribute - and hence I can't store my stylesheets in Xindice. (The document was added using the command line tools, if that makes any difference).
Now, if someone knows a quick fix for this, or if it has already been fixed in CVS, please let me know, and I promise not to get too mad for having spent the last three hours tracking down why Xalan is failing on me and looking into where Xindice is going wrong. 8)
If not, I'll happily find the bug and fix it, but it would help greatly if I could see what Xindice is storing in it's data files, so I can determine if the invalid NS URI is creeping in at document creation time or when it is retreived. If someone could provide some pointers here, I'd appreciate it.
Also, I assume xml.dom.DOMParser is used by the server to parse incoming XML strings when creating or storing new documents. Is this correct?
Thanks, Mike.
-- Mike Gratton <[EMAIL PROTECTED]> "Every motive escalate." Blatant self-promotion: <http://web.vee.net/>
