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]
