Right now we have the element names "Jdbc" and "SMTP".
Should we use CamelCase for acronyms ("JDBC") or treat an acronym as a word
("Jdbc")?
Gary
On Wed, Aug 14, 2013 at 4:00 PM, Gary Gregory <garydgreg...@gmail.com>wrote:
> On Wed, Aug 14, 2013 at 3:10 PM, Ralph Goers
> <ralph.go...@dslextreme.com>wrote:
>
>> 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
>>
>>
> Roger that!
>
> Gary
>
>
>> On Aug 14, 2013, at 9:45 AM, Gary Gregory wrote:
>>
>> On Wed, Aug 14, 2013 at 12:30 PM, Ralph Goers <ralph.go...@dslextreme.com
>> > 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
>>> <garydgreg...@gmail.com>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 <
>>>> nicho...@nicholaswilliams.net> 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: log4j-dev-unsubscr...@logging.apache.org
>>>>> For additional commands, e-mail: log4j-dev-h...@logging.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
>>>> 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: garydgreg...@gmail.com | ggreg...@apache.org
>> 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
>>
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> 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
>
--
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
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
