I have no problem with these changes John.
Gareth
On 11 Apr 2008, at 16:57, John Snelson wrote:
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]
--
Gareth Reakes, CTO WE7
+44-20-7117-0809 http://www.we7.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
