Hey,
I feel we really should move to the latest version of the spec, even if we don't fully implement it. Its difficult for new users, users who are using both c + j and it makes the project seem like not a lot is happening - even though that is not true.
If we do move, it does make sense to me to get rid of the old interfaces, and therefore go to Xerces 3.0. Having them hanging around will only be confusing. Any one else any feelings on this?
Gareth
Alberto Massari wrote:
Hi David,
At 12.18 04/02/2005 -0500, David Cargill wrote:
Hi Alberto, Adding /Wp64 sounds fine.
I am not sure about having the next release be 3.0. I think the risk of
someone having PSVIDefs in their code is a small risk (given that we have
already removed the functionality). I agree it would be nice to clean up a
number of items but I think 3.0 should have some significant functionality
or architectural change from the current code base. However, this is just
my opinion, and I wonder what others think? Anyone?
We discussed about the same issue before 2.6; at that time I was proposing to delete those PSVI methods from the XMLElementDecl/XMLAttDef classes as part of the new implementation for DOMTypeInfo, but our policy only allowed us to mark them as deprecated. The alternative (releasing a 3.0 version) was not considered a viable choice (because no major features were introduced).
What has changed now? We simply have more deprecated stuff to remove, but no new features yet. So, either we keep adhering to the policy (and keep those enums around for a little more time), or we start working for a 3.0 release, scheduling the work for those features that would break source code compatibility.
BTW, what is the outstanding work for DOML3? If methods have changed names, could we introduce the new names and mark the old ones as deprecated?
This is what I found doing a quick comparison between the specs (Load & Save and Core) and the source code:
DOMImplementationLS interface: - createDOMBuilder is now createLSBuilder - createDOMWriter is now createLSSerializer - createDOMInputSource is now createLSInput - a new createLSOutput method has been added
DOMBuilder interface:
- its name is now DOMLSParser
- new enum value ACTION_REPLACE_CHILDREN, and numeric values for the others have been changed
- getErrorHandler, getEntityResolver, getFeature, canSetFeature have been removed
- new abort() method
DOMInputSource interface: - its name is now DOMLSInput: - a new certifiedText attribute - 3 ways to get text: characterStream, byteStream, stringData
DOMEntityResolver interface: - its name is now DOMLSResourceResolver - resolveEntity is now resolveResource
DOMNodeFilter interface: - its name is now DOMLSParserFilter - new enum FILTER_INTERRUPT - new method startElement - new attribute whatToShow
DOMWriter interface: - its name is now DOMLSSerializer - features and encoding are enclosed in a DOMConfiguration attribute - writeNode() is now write() - new writeToURI method
DOMWriterFilter interface: - its name is now DOMLSSerializerFilter
DOMBuilderFilter is now DOMLSParserFilter:
- it has just a whatToShow attribute, but it looks like we don't even define the interface (it's just a forward declaration)
DOMNode interface:
- compareTreePosition() has been changed into compareDocumentPosition(), with different enums
- lookupNamespacePrefix() is now lookupPrefix()
- getInterface() is now getFeature()
DOMElement interface:
- the setIdAttribute, setIdAttributeNS, setIdAttributeNode now have a boolean flag as last argument
DOMText interface:
- a new method isElementContentWhitespace replaces the non-standard method isIgnorableWhitespace
DOMTypeInfo interface: - a new method isDerivedFrom has been introduced
DOMUserDataHandler interface: - a new enum, NODE_ADOPTED
DOMLocator interface: - getOffset should be duplicated into getUtf16Offset and getByteOffset - getErrorNode is now getRelatedNode
DOMConfiguration interface: - a new parameterNames attribute
DOMEntity interface: - getEncoding/getActualEncoding are now getInputEncoding/getXmlEncoding - getVersion is now getXmlVersion
DOMDocument: - getEncoding/getActualEncoding are now getInputEncoding/getXmlEncoding - getStandalone is now getXmlStandalone - getVersion is no getXmlVersion - getDOMConfiguration is now getDomConfig
All in all, source code compatibility could be maintained, creating new classes instead of renaming them, and adding new methods for the ones that changed names. But clearly the amount of deprecated code in the parser would grow (e.g. we already have questions on why there is a XercesDOMParser and a DOMBuilder; now we would have those two plus DOMLSParser)
Maybe we should also keep track (perhaps in a Jira bug) of changes we
should make for the next version of xercesc (you mentioned adding const to
some signatures). It would be good if we didn't lose track of these...
I was referring to these three Jira bugs:
- XERCESC-783: DOMUserDataHandler::handle specifies src and dst as const DOMNode*, but the specs say they are DOMNode* (and the user wants to modify them)
- XERCESC-1153: XMLSchemaDescriptionImpl::getLocationHints should return a const object to prevent attempts to change its state
- XERCESC-1223: DOMDocument::importNode should declare the source node as const DOMNode*
What do users think about this issue?
Alberto
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Gareth Reakes, Managing Director Parthenon Computing +44-1865-811184 http://www.parthcomp.com
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
