Hi everyone,
Boris Kolpackov and I were just having a discussion over on the XQilla
mailing list. He suggested that now was the time to make a few changes
in the Xerces-C API to benefit XQilla - so I've written a proposal for
what I'd like to change.
I'll give as much help as I can in making these changes, but at the
moment I'm going through the process of getting permission to sign the
contributor agreement.
Please let me know your opinions on making these changes.
John
---------------------------------------------------------
1) Problem:
XPath 2.0 is just different to XPath 1.0. We've therefore got our own
version of DOMXPathResult (XPath2Result) which makes more sense in this
context:
http://xqilla.sourceforge.net/docs/dom3-api/classXPath2Result.html
Solution:
It's probably simple enough to either extend DOMXPathResult to include
the extra functionality in XPath2Result, or to include it as a new class
called DOMXPath2Result.
---------------------------------------------------------
2) Problem:
It's necessary to get access to DOMDocumentImpl, which isn't in the
public API, in order to implement the DOM3 XPath API. Needing access to
the Xerces-C source code to compile XQilla is a big problem for our
maintainers. We need DOMDocumentImpl for a number of reasons:
a) In order to implement DOMXPathNamespace, we need to allocate using
the DOMDocumentImpl's memory manager and string pool.
b) We need to access DOMDocumentImpl::changes() to invalidate the xpath
result iterator if the DOMDocument is changed
(DOMXPathResult::getInvalidIteratorState()).
c) XQuery allows a document node to contain multiple document elements.
We derive from DOMDocumentImpl to allow that to happen.
d) In order to implement the DOMXPathEvaluator interface on the
DOMDocument object we need to derive from DOMDocumentImpl.
Solution:
Put DOMDocumentImpl in the public API.
---------------------------------------------------------
3) Problem:
We need access to DOMWriterImpl in order to override it to know how to
write namespace nodes. DOMWriterImpl isn't in the public API.
Solution:
Put DOMWriterImpl in the public API, or implement namespace node
handling in it.
---------------------------------------------------------
4) Problem:
XQilla can construct typed DOMDocuments, so we need a way to set the
type information on these nodes. Currently we use DOMTypeInfoImpl,
DOMAttrImpl and DOMElementNSImpl to do this, which aren't in the public API.
Solution:
Implement a method of setting the type information on an element or
attribute, or put DOMTypeInfoImpl, DOMAttrImpl and DOMElementNSImpl in
the public API.
---------------------------------------------------------
5) Problem:
RegularExpression is not thread safe or consistent with it's use of
MemoryManager. It's also not quite flexible enough to implement XSLT
2.0's analyze-string, and it has bugs in the replace() methods.
http://www.w3.org/TR/xslt20/#analyze-string
Solution:
I have a patch that fixes all of this in Xerces-C 2.8, and I can update
it to apply to 3.0. I'm in the process of getting permission to sign the
contributor agreement.
---------------------------------------------------------
6) Problem:
The socket and WinSock HTTP InputStream implementations have fixed
buffers which can result in buffer overflow. They needlessly duplicate a
whole load of code that could be shared. In addition, a lot of
algorithms need access to the HTTP "Content-Type" header, to decide how
to parse a file, or what encoding it is in - for instance see XSLT 2.0's
unparsed-text() function:
http://www.w3.org/TR/xslt20/#unparsed-text
Solution:
I have a patch that implements this functionality for
UnixHTTPURLInputStream and BinHTTPURLInputStream (WinSock) in Xerces-C
2.8. I added BinInputStream::getContentType() to get access to the
"Content-Type" header. I can update this code for Xerces-C 3.0.
---------------------------------------------------------
7) Problem:
GrammarResolver has a bug where it fails to initialize it's XSModel if
the XMLGrammarPool it is created with is locked.
Solution:
We hack this at the moment, but it would be great if this could be fixed.
--
John Snelson, Oracle Corporation http://snelson.org.uk/john
Berkeley DB XML: http://oracle.com/database/berkeley-db/xml
XQilla: http://xqilla.sourceforge.net
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
