Hi John, John Snelson <[EMAIL PROTECTED]> writes:
> Having given it some thought, I think that merging the two would be the > best idea - it would be a breaking change for XQilla users, but it would > be a move to a more standard API. Agree. If you can come up with a patch, I will review and commit it. > I think that some headers related to DOMDocumentImpl are also needed. An > exhaustive list of the ones that XQilla includes are these: > > [...] > > I imagine that you also need to include the headers that these files > include themselves. All headers in dom/impl/ are now installed. I also checked and none of them include anything from internal/ so I thing there won't be any problems. Though it is always better to check that we are not missing anything on the real use-case. Are you planning to start working on the 3.0.0 port of XQilla before the release? > I've got permission now - hurrah! In the next couple of days when I find > some time I'll port the patches over to Xerces-C 3.0. That's great news! > I looked into the MacOS net accessors, and it seemed to be impossible to > support this API with them. However, recent email on the list suggests > that these implementations have other problems (a problem with fork?). > > Since you won't get any content type information back for file URLs > either, I'd suggest that a null return should be the standard response > when the content type is unavailable. I agree. If there is no easy way to support this with non-mainstream net accessors then we should simply return NULL. Boris -- Boris Kolpackov, Code Synthesis Tools http://codesynthesis.com/~boris/blog Open source XML data binding for C++: http://codesynthesis.com/products/xsd Mobile/embedded validating XML parsing: http://codesynthesis.com/products/xsde --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
