Re: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
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:
RE: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
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. It definitely looks that way from the outside in the areas of DOM and XSD. So if indeed you can support DOM3 sooner rather than later, +1 from me. 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? +1. However, I think a concerted effort to close some outstanding bugs ought to be made if you go to 3.0, because those of us maintaining our own patches will be stuck without full DOM3 support otherwise. xml:lang support and proper base64 handling during validation are still the top problems for me. -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
Hi Scott, In the last version of Xerces-C, there was fix for the DOM normalization problem. When the feature is set to false, you'll get back the non schema normalized value. Is this still a problem for you? Khaled Scott Cantor [EMAIL PROTECTED] 02/08/2005 10:46 AM Please respond to xerces-c-dev To xerces-c-dev@xml.apache.org cc Subject RE: Request for feedback on some proposed xercesc changes (including breaking source code compatibility) 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. It definitely looks that way from the outside in the areas of DOM and XSD. So if indeed you can support DOM3 sooner rather than later, +1 from me. 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? +1. However, I think a concerted effort to close some outstanding bugs ought to be made if you go to 3.0, because those of us maintaining our own patches will be stuck without full DOM3 support otherwise. xml:lang support and proper base64 handling during validation are still the top problems for me. -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
In the last version of Xerces-C, there was fix for the DOM normalization problem. When the feature is set to false, you'll get back the non schema normalized value. Is this still a problem for you? That particular approach is not ideal (and it's a fairly old fix, not recent), but more importantly, there was a change in 2.6 such that when validation is on (and regardless of the data normalization setting), a strict base64 validator is applied that cannot validate unnormalized base64 data. It has to do with checking the number of bytes to be a multiple of 4, and the line breaks you leave in cause the multiple to be something else. IOW, you can leave normalization on and break your signature, or leave it off and fail to even validate. I raised this problem and got a response that seemed to indicate the solution was to fix Xerces to store off the normalized value in a separate bucket for the schema validation step to use instead of overwriting the actual DOM. That seems to be what XercesJ is doing, at least it appears to actually support validation and normalization now without breaking signatures. I can probably find the thread if you like, but if you search for my address, you should find it in the archives. I think I filed a bug on this, but the problem is it's not precisely a bug, more of a mismatch between XML specifications. -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
That's the fix that I'm talking about. The DOM will store the non schema normalized value (when validation is on and the dom normalization feature is off). Khaled Scott Cantor [EMAIL PROTECTED] 02/08/2005 11:26 AM Please respond to xerces-c-dev To xerces-c-dev@xml.apache.org cc Subject RE: Request for feedback on some proposed xercesc changes (including breaking source code compatibility) In the last version of Xerces-C, there was fix for the DOM normalization problem. When the feature is set to false, you'll get back the non schema normalized value. Is this still a problem for you? That particular approach is not ideal (and it's a fairly old fix, not recent), but more importantly, there was a change in 2.6 such that when validation is on (and regardless of the data normalization setting), a strict base64 validator is applied that cannot validate unnormalized base64 data. It has to do with checking the number of bytes to be a multiple of 4, and the line breaks you leave in cause the multiple to be something else. IOW, you can leave normalization on and break your signature, or leave it off and fail to even validate. I raised this problem and got a response that seemed to indicate the solution was to fix Xerces to store off the normalized value in a separate bucket for the schema validation step to use instead of overwriting the actual DOM. That seems to be what XercesJ is doing, at least it appears to actually support validation and normalization now without breaking signatures. I can probably find the thread if you like, but if you search for my address, you should find it in the archives. I think I filed a bug on this, but the problem is it's not precisely a bug, more of a mismatch between XML specifications. -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
That's the fix that I'm talking about. The DOM will store the non schema normalized value (when validation is on and the dom normalization feature is off). I understand that. But the Base64 datatype validator has a new flag in 2.6 that causes a strict validation against the DOM-stored value. That check now fails in 2.6, therefore turning that flag off breaks schema validation. The fix I'm talking about is that if Xerces wants to strictly validate datatypes based on assuming normalization, it needs to store *both* values and use the one that's appropriate for the operation. See http://marc.theaimsgroup.com/?l=xerces-c-devm=109880001621887w=2 -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
Hi Scott, The way it used to work for validating character content, was to normalize the value before passing it on to the datatype validator. If validation is successfull we pass the normalized value to the doucment handler. In the DOM case, the document handler will be a DOM parser, and the parser will create the appropriate DOM tree which will store the normalized value. There's a fix after 2.6 that changed the way values are stored in the DOM tree. When validating a data content, the orignal value is normalized according to the whitespace facet, and passed on to the datatype validators. For the DOM case, If the datatype-normalization feature is enabled, we pass back the normalized value, if it's disabled, we pass back the original value. So, for validation we always use the normalized value, however for the value we store in the DOM tree, we either store the normalized or non-normalized value depending on the datatype-normalization feature. Khaled Scott Cantor [EMAIL PROTECTED] 02/08/2005 11:45 AM Please respond to xerces-c-dev To xerces-c-dev@xml.apache.org cc Subject RE: Request for feedback on some proposed xercesc changes (including breaking source code compatibility) That's the fix that I'm talking about. The DOM will store the non schema normalized value (when validation is on and the dom normalization feature is off). I understand that. But the Base64 datatype validator has a new flag in 2.6 that causes a strict validation against the DOM-stored value. That check now fails in 2.6, therefore turning that flag off breaks schema validation. The fix I'm talking about is that if Xerces wants to strictly validate datatypes based on assuming normalization, it needs to store *both* values and use the one that's appropriate for the operation. See http://marc.theaimsgroup.com/?l=xerces-c-devm=109880001621887w=2 -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
normalized value. There's a fix after 2.6 that changed the Sorry, when you said last version, I assumed you meant either 2.5 or 2.6, but not unreleased cvs. ;-) What you describe is indeed the fix I expected. -- Scott - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
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
Re: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
On 3 Feb 2005, at 14:10, Jesse Pelton wrote: Makes sense to me, except for one detail: I think names specified in standards should specifically be exempted from the proposed Mixed Case guideline. Such names should match the casing used in the standard. To meet this guideline without such an exemption, names such as node types, filter actions, error severity levels, and so on would have to be transformed in some way. TEXT_NODE, for example, would become Text_Node, TextNode, or something else. I completely agree with this. I thought it was implied in the original statement - if not then this is a caveat of mine as well. Cheers, Gareth -- 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]
Re: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
Hey, Whats your objection against 3.0? Gareth 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? 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? 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... Regards, David A. Cargill XML Parser Development IBM Toronto Lab (905) 413-2371, tie 969 [EMAIL PROTECTED] Alberto Massari [EMAIL PROTECTED] ect.com To xerces-c-dev@xml.apache.org 02/03/2005 06:29 cc AM Subject Re: Request for feedback on some Please respond to proposed xercesc changes xerces-c-dev(including breaking source code compatibility) Hi David, At 05.59 03/02/2005 -0500, David Cargill wrote: Hi All, In reviewing some recent appends and Jira bugs I would like to get some feedback before making the following changes: (1) Change compiler options for Linux and MSVC++ to generate more warning messages. By regularly monitoring the regular builds of xercesc we can try and have warning free builds. The proposed options for Linux are: CFLAGS += -W -Wall -Wno-parentheses -Wshadow -Wcast-align -Winline -Wstrict-prototypes CXXFLAGS += -W -Wno-parentheses -Wcast-align -Wstrict-prototypes For MSVC++ use W4. These look fine; for MSVC++ 7.1 we should also turn on /Wp64, in order to catch instructions that on a 64-bit platform have unwanted side effect (long!=size_t) (2) Change PSVIDefs to remove the following enums and remove the corresponding methods that use them in SchemaElementDecl and SchemaAttDef: [...] What about planning to release Xerces-C++ 3.0 as the next release, as the current policy would require? This way we have the chance to clean up the enums, add some const keywords to some signatures, and complete the work on DOML3 (that requires renaming some methods that have changed signature since the working draft we implemented). Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
Re: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
Hi Gareth, I would like to know what the proposed changes are for a xercesc 3.0 release. The current release plan (http://xml.apache.org/xerces-c/releases_plan.html) is blank. Do you have a detailed list of what changes would be made for 3.0 (ie. what new things will be added and just as importantly what deprecated items will be removed)? I am hesitant to rip out everything that is marked deprecated, as some things haven't been marked deprecated for very long (ie. SAXParser) and even though the deprecated DOM has been marked deprecated for a while it is still being used. Regards, David A. Cargill XML Parser Development IBM Toronto Lab (905) 413-2371, tie 969 [EMAIL PROTECTED] Gareth Reakes [EMAIL PROTECTED] computing.com To xerces-c-dev@xml.apache.org 02/04/2005 12:18 cc PM Subject Re: Request for feedback on some Please respond to proposed xercesc changes xerces-c-dev(including breaking source code compatibility) Hey, Whats your objection against 3.0? Gareth 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? 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? 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... Regards, David A. Cargill XML Parser Development IBM Toronto Lab (905) 413-2371, tie 969 [EMAIL PROTECTED] Alberto Massari [EMAIL PROTECTED] ect.com To xerces-c-dev@xml.apache.org 02/03/2005 06:29 cc AM Subject Re: Request for feedback on some Please respond to proposed xercesc changes xerces-c-dev(including breaking source code compatibility) Hi David, At 05.59 03/02/2005 -0500, David Cargill wrote: Hi All, In reviewing some recent appends and Jira bugs I would like to get some feedback before making the following changes: (1) Change compiler options for Linux and MSVC++ to generate more warning messages. By regularly monitoring the regular builds of xercesc we can try and have warning free builds. The proposed options for Linux are: CFLAGS += -W -Wall -Wno-parentheses -Wshadow -Wcast-align -Winline -Wstrict-prototypes CXXFLAGS += -W -Wno-parentheses -Wcast-align -Wstrict-prototypes For MSVC++ use W4. These look fine; for MSVC++ 7.1 we should also turn on /Wp64, in order to catch instructions that on a 64-bit platform have unwanted side effect (long!=size_t) (2) Change PSVIDefs to remove the following enums and remove the corresponding methods that use them in SchemaElementDecl and SchemaAttDef: [...] What about planning to release Xerces-C++ 3.0 as the next release, as the current policy would require? This way we have the chance to clean up the enums, add some const keywords to some signatures, and complete the work on DOML3 (that requires renaming some methods that have changed signature since the working draft we implemented). Alberto - To unsubscribe, e-mail: [EMAIL
Re: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
Hi David, At 05.59 03/02/2005 -0500, David Cargill wrote: Hi All, In reviewing some recent appends and Jira bugs I would like to get some feedback before making the following changes: (1) Change compiler options for Linux and MSVC++ to generate more warning messages. By regularly monitoring the regular builds of xercesc we can try and have warning free builds. The proposed options for Linux are: CFLAGS += -W -Wall -Wno-parentheses -Wshadow -Wcast-align -Winline -Wstrict-prototypes CXXFLAGS += -W -Wno-parentheses -Wcast-align -Wstrict-prototypes For MSVC++ use W4. These look fine; for MSVC++ 7.1 we should also turn on /Wp64, in order to catch instructions that on a 64-bit platform have unwanted side effect (long!=size_t) (2) Change PSVIDefs to remove the following enums and remove the corresponding methods that use them in SchemaElementDecl and SchemaAttDef: [...] What about planning to release Xerces-C++ 3.0 as the next release, as the current policy would require? This way we have the chance to clean up the enums, add some const keywords to some signatures, and complete the work on DOML3 (that requires renaming some methods that have changed signature since the working draft we implemented). Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Request for feedback on some proposed xercesc changes (including breaking source code compatibility)
Makes sense to me, except for one detail: I think names specified in
standards should specifically be exempted from the proposed Mixed Case
guideline. Such names should match the casing used in the standard.
To meet this guideline without such an exemption, names such as node
types, filter actions, error severity levels, and so on would have to be
transformed in some way. TEXT_NODE, for example, would become
Text_Node, TextNode, or something else.
Such a change seems unnecessary and undesireable to me. As the DOM spec
points out, DOM names tend to be long and descriptive in order to be
unique across all environments. As far as I'm aware, there haven't
been reports of names from specifications being defined as constants by
other projects.
Furthermore, if any transformation of these names is applied, it will
make the implementation harder to use. Xerces exists in part to provide
an implementation of the W3C's DOM-related standards, which means the
standards are useful reference materials for Xerces users, and it's easy
to move between implementations. (If you work with JavaScript, Java,
and C++ DOM implementations, it is helpful to be able to rely on element
nodes having type ELEMENT_NODE.) If the names Xerces uses don't match
the names in the standards, that diminishes the synergy, opens the door
for confusion, and (in my mind) invalidates Xerces' claim to be an
implementation of the DOM specifications.
-Original Message-
From: David Cargill [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 03, 2005 5:59 AM
To: xerces-c-dev@xml.apache.org
Subject: Request for feedback on some proposed xercesc
changes (including breaking source code compatibility)
Hi All,
In reviewing some recent appends and Jira bugs I would like
to get some
feedback before making the following changes:
(1) Change compiler options for Linux and MSVC++ to generate
more warning
messages. By regularly monitoring the regular builds of
xercesc we can try and have warning free builds. The proposed
options for Linux are:
CFLAGS += -W -Wall -Wno-parentheses -Wshadow
-Wcast-align -Winline
-Wstrict-prototypes
CXXFLAGS += -W -Wno-parentheses -Wcast-align -Wstrict-prototypes
For MSVC++ use W4.
(2) Change PSVIDefs to remove the following enums and remove the
corresponding methods that use them in SchemaElementDecl and
SchemaAttDef:
enum Validity {
UNKNOWN = 1,
INVALID = 2,
VALID = 3
};
enum Validation {
NONE= 1,
PARTIAL = 2,
FULL= 3
};
enum Complexity {
SIMPLE = 1,
COMPLEX = 2
};
All of the methods that use these enums are marked
deprecated and the
xercesc code is not making calls to them anymore (ie. the values are
initialized but
the code no longer makes calls to update them). So if anyone were
making calls to these functions they would always be getting the same
values back.
According to the release policy[*] we are supposed to be
source code
compatible between releases but given that these enums have
values with ALL
CAPITAL names that are colliliding with other products it
seems like we
should clean this up now as opposed to the next version.
(3) A related change to the previous item, I propose updating
the xercesc
coding conventions [**] to indicate that for ENUMS the names should be
choosen to
be unique and descriptive (ie. INVALID or UNKNOWN are
not good names)
to avoid colliding with predefined macros in other products.
The current
style
of using ALL CAP enums should be phased out with using
Mixed Case
enums instead (to minimize the potential of colliding with predefined
macros in the
future).
[*] http://xml.apache.org/xerces-c/faq-contributing.html#faq-2
[**] http://xml.apache.org/xerces-c/faq-contributing.html#faq-3
Regards,
David A. Cargill
XML Parser Development
IBM Toronto Lab
(905) 413-2371, tie 969
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
