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<http://www.manning.com/bauer3/>
>> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
>> Spring Batch in Action <http://www.manning.com/templier/>
>> 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<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Reply via email to