To be clear,   i am fine with establishing the convention you are suggesting by 
making sure all the tests, examples and documentation follow it.

Ralph

On Aug 14, 2013, at 9:45 AM, Gary Gregory wrote:

> On Wed, Aug 14, 2013 at 12:30 PM, Ralph Goers <[email protected]> 
> wrote:
> I'm fine with Gary's conventions.  But... they should only matter when 
> validating against the XSD.  My preference is to leave the code alone and 
> keep ignoring the case.
> 
> OK, let's keep the case business separate for now. If I use casing that does 
> not follow what is in the XSD, then obviously, my XML will not validate, as 
> expected.
> 
> Tracking here: https://issues.apache.org/jira/browse/LOG4J2-353
> 
> Gary
> 
> 
> 
> Ralph
> 
> On Aug 14, 2013, at 8:26 AM, Paul Benedict wrote:
> 
>> I know everyone has a certain convention they like, but I don't like 
>> multiple conventions. I think elements and attributes should follow the same 
>> convention. Whether you do TitleCase, or lowercase, or camelCase, just be 
>> consistent for it all.
>> 
>> PS: Personally, I do lower case with dashes. That's what I think is easiest 
>> to remember. But as long as the rule is the same for both, that's what I 
>> definitely think we should have.
>> 
>> Paul
>> 
>> 
>> On Wed, Aug 14, 2013 at 10:22 AM, Gary Gregory <[email protected]> 
>> wrote:
>> I am renaming this thread from "Config XSD naming convention" to "Config 
>> files naming conventions" because it is not just about the XSD, so let me 
>> rephrase:
>> 
>> I find the mixed use of naming conventions messy and confusing and for lack 
>> of a better term, not very "pro" as in "professional". 
>> 
>> I'd like to use the following convention in the XML configs, which I've used 
>> in the log events XSD:
>> 
>> - Elements are CamelCase
>> - Attributes are camelCase
>> 
>> This is just like ClassNames and instanceVariables in Java and other 
>> languages.
>> 
>> This means that I would also like to change names I am sure I am not alone 
>> in finding abhorrent: "some-ref", which would become SomeRef for an element 
>> and someRef for an attribute.
>> 
>> The fact that the current code is case-insensitive is an oddity I'd rather 
>> not document such that XML Validation can work based on the conventions 
>> above.
>> 
>> At work, we generate Log4j 1 configurations from a proprietary GUI tool, and 
>> soon Log4j 2 :) so any perceived convenience of case-insensitivity is not 
>> only wasted on us but also can lead to false errors when used with XML 
>> validation. It's always a good idea to validate XML as a sanity check before 
>> sending it out in the real world. 
>> 
>> Gary
>> 
>> On Sat, Aug 10, 2013 at 12:01 PM, Nick Williams 
>> <[email protected]> wrote:
>> 
>> On Aug 10, 2013, at 10:57 AM, Gary Gregory wrote:
>> 
>> > Hi All:
>> >
>> > I'd like to use the following convention in the XML config XSD [1], which 
>> > I've used in the events XSD [2]:
>> >
>> > - Elements are CamelCase
>> > - Attributes are camelCase
>> 
>> +1
>> 
>> >
>> > Just like ClassNames and instanceVariables in Java.
>> >
>> > After that, I would also like to change names I am sure I am not alone in 
>> > finding abhorant: some-ref, which would become someRef.
>> 
>> I actually really like hyphenated attributes, but I like consistency better.
>> 
>> Nick
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>> 
>> 
>> 
>> 
>> -- 
>> E-Mail: [email protected] | [email protected] 
>> Java Persistence with Hibernate, Second Edition
>> JUnit in Action, Second Edition
>> Spring Batch in Action
>> Blog: http://garygregory.wordpress.com 
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>> 
>> 
>> 
>> -- 
>> Cheers,
>> Paul
> 
> 
> 
> 
> -- 
> E-Mail: [email protected] | [email protected] 
> Java Persistence with Hibernate, Second Edition
> JUnit in Action, Second Edition
> Spring Batch in Action
> Blog: http://garygregory.wordpress.com 
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

Reply via email to