You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commonsrdf.apache.org by Reto Gmür <re...@apache.org> on 2015/03/17 10:51:09 UTC
Casing: RdfTerm or RDFTerm?
I know it's just a detail and there is no clear right or wrong. Still I'd
like to have a conscious decision on how to do the casing so we can apply
it consistently everywhere.
Approaches:
A) Acronyms are treated like normal words, i.e. only the first character is
uppercased, this is what the google style guide recommends [1]
B) Acronyms are uppercased as a whole
C) 2-Letter acronyms are uppercased, longer are treated like normal words
(this seems to be the .Net convention)
I personally prefer the first approach for the following reasons:
- IDEs get it right, the default name for the result of getRdfUiApiKey() or
a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or apiKey, or key)
not rDFUIAPIKey.
- It's more readable, the acronyms are the individual words, the case
distinctions allows to recognize them quickly
- It's not always obvious is something is an abbreviation or any acronym,
while it might seem OK to uppercase some abbreviations like "OK" or "ID"
uppercasing other abreviations would look quite strange (e.g.
"LiteralIMPL"). So for consistency treat acronyms like abbreviations like
normal words.
WDYT?
Reto
1.
https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
Re: Casing: RdfTerm or RDFTerm?
Posted by Reto Gmür <re...@apache.org>.
Hi Peter
I fully agree that Commons RDF shall be implementation independent. This is
also a reason why I oppose introducing artifacts that are not into the RDF
Model and abstract syntax into the API. Introducing things like BNode IDs
work well with some backends but bad with others, that's why I think they
should not be part of the API,
Clerezza, even its most basic core, is an implementation under the
> assumptions we have been using since we setup the project. One main
> assumption that we have been following is that we are setting up
> something completely independent from any existing code to give the
> project the best chance of succeeding, politically speaking.
>
It might have been politically wiser to start with two project from
beginning, one for the vendor independent API and one for the
Web-Application platform on top of it. Anyway, now we have a new project
for the API and if this is generic enough there is no reason it shouldn't
replace the clerezza RDF API. The Clerezza Adapter implementing the RDF Api
on top Jena and Sesame would then become obsolete.
As it says in the guidelines, the resulting library will live or die
> on their merits, and no particular implementation is being forced to
> use the library if there is a reason why it doesn't fit and that can't
> be negotiated through.
>
What guidelines are you referring to?
>
> However, there is no technical reason why Clerezza cannot simply
> implement the interfaces as they are currently defined without the
> interface names being changed, and hence it seems like you are still
> pushing your particular implementation on the Commons RDF project.
>
This is ridiculous, of course clerezza can use any name. In fact I've
refactored clerezza to use the names as in your code proposal on Github.
After the rename from Resource to RDFNode they where better than the one in
clerezza. The only deviation from your proposal is the casing, it wouldn't
have been more work to change that too. And once there is a decision here
on a convention I will propose to clerezza to use the same convention. The
important thing is that we have a convention and to speak with Kant, a good
convention is one that we can at the same time will that it should become a
universal convention without contradiction.
For me the best such convention is to threat acronyms as words. There are
good argument for other conventions, just referring to the proposed code on
github is however not one of these good arguments.
Cheers,
Reto
>
> Thanks,
>
> Peter
>
> On 25 March 2015 at 09:04, Reto Gmür <re...@apache.org> wrote:
> > Hi Peter
> >
> > In addition, we are explicitly aiming not to be biased towards any of
> >> the potential implementations, and your proposal is based solely on
> >> fitting with your potential implementation.
> >>
> >
> > Clerezza is not a potential implementation, part of clerezza is about
> > proving a vendor independent API for RDF. The hope is that this API and
> the
> > clerezza core RDF API will converge and that there will be a single
> commons
> > RDF API.
> >
> > The current clerezza version of commons RDF treats acronyms as words,
> this
> > is not an argument for using this convention. Similarly I think the
> current
> > code proposal on Github is not an argument for having it another way.
> >
> > I'm happy to change the clerezza commons RDF code, I would prefer to do
> > this before the first release and I would like to avoid changing the code
> > multiple times, so I would like to have a decision that is meant to last.
> > This is not argument for any version but just to explain why I am
> insisting
> > on this matter.
> >
> > Cheers,
> > Reto
> >
> >
> >
> >>
> >> Thanks,
> >>
> >> Peter
> >>
> >> On 23 March 2015 at 21:16, Reto Gmür <re...@apache.org> wrote:
> >> > Right now we have negectable costs of changing, later it will mean an
> >> > incompatible change.
> >> >
> >> > So while I'm fully aware that "Projects using the library make their
> own
> >> > decisions", I nevertheless think that it is an advantage for Clerezza
> to
> >> > use the same convention as what will be its most important library and
> >> most
> >> > frequently used types.
> >> >
> >> > I suggest we have a vote and then stick to the decision.
> >> >
> >> > IIUC we have two proposals:
> >> >
> >> > a) Acronyms are treated like normal words, i.e. only the first
> character
> >> is
> >> > uppercased, this is what the google style guide recommends
> >> >
> >> > d) If possible acronyms are cased as they appear in the specs (default
> >> > casing), if they appear in a position where an uppercase first letter
> is
> >> > required (and this letter is not uppercase in the default casing) then
> >> only
> >> > this letter is uppercased, if they appear in a position where a
> lowercase
> >> > first letter is required then the whole acronym is lowercased. Where
> >> > obvious readability improvements result a different casing can be
> chosen.
> >> >
> >> > If I correctly described the proposals that have some support, we can
> >> have
> >> > a vote on which one to pick.
> >> >
> >> > Cheers,
> >> > Reto
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Mon, Mar 23, 2015 at 9:57 AM, Stian Soiland-Reyes <
> stain@apache.org>
> >> > wrote:
> >> >
> >> >> +1 - if we end up with say SPARQLRDFXMLSerializer (which would be out
> >> >> of scope now!) then revisit - stay with current names for now.
> >> >>
> >> >> On 22 March 2015 at 20:56, Peter Ansell <an...@gmail.com>
> wrote:
> >> >> > On 21 March 2015 at 20:25, Reto Gmür <re...@apache.org> wrote:
> >> >> >>> You had then gone on to refer to the case of
> >> >> >>> possibly having multiple acronyms, which we do not have.
> >> >> >>>
> >> >> >>
> >> >> >> I started the discussion with the goal "to do the casing so we can
> >> >> apply it
> >> >> >> consistently everywhere" and I mentioned the situation of multiple
> >> >> acronyms
> >> >> >> in my first mail.
> >> >> >
> >> >> > At this point, our entire scope is what we have right now, and
> there
> >> >> > is no specific benefit to switching to 'acronyms as words' within
> that
> >> >> > scope. If the scope expands to those cases in the future, before a
> 1.0
> >> >> > release, we can revisit the issue.
> >> >> >
> >> >> > Thanks,
> >> >> >
> >> >> > Peter
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> Stian Soiland-Reyes
> >> >> Apache Taverna (incubating), Apache Commons RDF (incubating)
> >> >> http://orcid.org/0000-0001-9842-9718
> >> >>
> >>
>
Re: Casing: RdfTerm or RDFTerm?
Posted by Peter Ansell <an...@gmail.com>.
Hi Reto,
Clerezza, even its most basic core, is an implementation under the
assumptions we have been using since we setup the project. One main
assumption that we have been following is that we are setting up
something completely independent from any existing code to give the
project the best chance of succeeding, politically speaking.
As it says in the guidelines, the resulting library will live or die
on their merits, and no particular implementation is being forced to
use the library if there is a reason why it doesn't fit and that can't
be negotiated through.
However, there is no technical reason why Clerezza cannot simply
implement the interfaces as they are currently defined without the
interface names being changed, and hence it seems like you are still
pushing your particular implementation on the Commons RDF project.
Thanks,
Peter
On 25 March 2015 at 09:04, Reto Gmür <re...@apache.org> wrote:
> Hi Peter
>
> In addition, we are explicitly aiming not to be biased towards any of
>> the potential implementations, and your proposal is based solely on
>> fitting with your potential implementation.
>>
>
> Clerezza is not a potential implementation, part of clerezza is about
> proving a vendor independent API for RDF. The hope is that this API and the
> clerezza core RDF API will converge and that there will be a single commons
> RDF API.
>
> The current clerezza version of commons RDF treats acronyms as words, this
> is not an argument for using this convention. Similarly I think the current
> code proposal on Github is not an argument for having it another way.
>
> I'm happy to change the clerezza commons RDF code, I would prefer to do
> this before the first release and I would like to avoid changing the code
> multiple times, so I would like to have a decision that is meant to last.
> This is not argument for any version but just to explain why I am insisting
> on this matter.
>
> Cheers,
> Reto
>
>
>
>>
>> Thanks,
>>
>> Peter
>>
>> On 23 March 2015 at 21:16, Reto Gmür <re...@apache.org> wrote:
>> > Right now we have negectable costs of changing, later it will mean an
>> > incompatible change.
>> >
>> > So while I'm fully aware that "Projects using the library make their own
>> > decisions", I nevertheless think that it is an advantage for Clerezza to
>> > use the same convention as what will be its most important library and
>> most
>> > frequently used types.
>> >
>> > I suggest we have a vote and then stick to the decision.
>> >
>> > IIUC we have two proposals:
>> >
>> > a) Acronyms are treated like normal words, i.e. only the first character
>> is
>> > uppercased, this is what the google style guide recommends
>> >
>> > d) If possible acronyms are cased as they appear in the specs (default
>> > casing), if they appear in a position where an uppercase first letter is
>> > required (and this letter is not uppercase in the default casing) then
>> only
>> > this letter is uppercased, if they appear in a position where a lowercase
>> > first letter is required then the whole acronym is lowercased. Where
>> > obvious readability improvements result a different casing can be chosen.
>> >
>> > If I correctly described the proposals that have some support, we can
>> have
>> > a vote on which one to pick.
>> >
>> > Cheers,
>> > Reto
>> >
>> >
>> >
>> >
>> >
>> > On Mon, Mar 23, 2015 at 9:57 AM, Stian Soiland-Reyes <st...@apache.org>
>> > wrote:
>> >
>> >> +1 - if we end up with say SPARQLRDFXMLSerializer (which would be out
>> >> of scope now!) then revisit - stay with current names for now.
>> >>
>> >> On 22 March 2015 at 20:56, Peter Ansell <an...@gmail.com> wrote:
>> >> > On 21 March 2015 at 20:25, Reto Gmür <re...@apache.org> wrote:
>> >> >>> You had then gone on to refer to the case of
>> >> >>> possibly having multiple acronyms, which we do not have.
>> >> >>>
>> >> >>
>> >> >> I started the discussion with the goal "to do the casing so we can
>> >> apply it
>> >> >> consistently everywhere" and I mentioned the situation of multiple
>> >> acronyms
>> >> >> in my first mail.
>> >> >
>> >> > At this point, our entire scope is what we have right now, and there
>> >> > is no specific benefit to switching to 'acronyms as words' within that
>> >> > scope. If the scope expands to those cases in the future, before a 1.0
>> >> > release, we can revisit the issue.
>> >> >
>> >> > Thanks,
>> >> >
>> >> > Peter
>> >>
>> >>
>> >>
>> >> --
>> >> Stian Soiland-Reyes
>> >> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> >> http://orcid.org/0000-0001-9842-9718
>> >>
>>
Re: Casing: RdfTerm or RDFTerm?
Posted by Reto Gmür <re...@apache.org>.
Hi Peter
In addition, we are explicitly aiming not to be biased towards any of
> the potential implementations, and your proposal is based solely on
> fitting with your potential implementation.
>
Clerezza is not a potential implementation, part of clerezza is about
proving a vendor independent API for RDF. The hope is that this API and the
clerezza core RDF API will converge and that there will be a single commons
RDF API.
The current clerezza version of commons RDF treats acronyms as words, this
is not an argument for using this convention. Similarly I think the current
code proposal on Github is not an argument for having it another way.
I'm happy to change the clerezza commons RDF code, I would prefer to do
this before the first release and I would like to avoid changing the code
multiple times, so I would like to have a decision that is meant to last.
This is not argument for any version but just to explain why I am insisting
on this matter.
Cheers,
Reto
>
> Thanks,
>
> Peter
>
> On 23 March 2015 at 21:16, Reto Gmür <re...@apache.org> wrote:
> > Right now we have negectable costs of changing, later it will mean an
> > incompatible change.
> >
> > So while I'm fully aware that "Projects using the library make their own
> > decisions", I nevertheless think that it is an advantage for Clerezza to
> > use the same convention as what will be its most important library and
> most
> > frequently used types.
> >
> > I suggest we have a vote and then stick to the decision.
> >
> > IIUC we have two proposals:
> >
> > a) Acronyms are treated like normal words, i.e. only the first character
> is
> > uppercased, this is what the google style guide recommends
> >
> > d) If possible acronyms are cased as they appear in the specs (default
> > casing), if they appear in a position where an uppercase first letter is
> > required (and this letter is not uppercase in the default casing) then
> only
> > this letter is uppercased, if they appear in a position where a lowercase
> > first letter is required then the whole acronym is lowercased. Where
> > obvious readability improvements result a different casing can be chosen.
> >
> > If I correctly described the proposals that have some support, we can
> have
> > a vote on which one to pick.
> >
> > Cheers,
> > Reto
> >
> >
> >
> >
> >
> > On Mon, Mar 23, 2015 at 9:57 AM, Stian Soiland-Reyes <st...@apache.org>
> > wrote:
> >
> >> +1 - if we end up with say SPARQLRDFXMLSerializer (which would be out
> >> of scope now!) then revisit - stay with current names for now.
> >>
> >> On 22 March 2015 at 20:56, Peter Ansell <an...@gmail.com> wrote:
> >> > On 21 March 2015 at 20:25, Reto Gmür <re...@apache.org> wrote:
> >> >>> You had then gone on to refer to the case of
> >> >>> possibly having multiple acronyms, which we do not have.
> >> >>>
> >> >>
> >> >> I started the discussion with the goal "to do the casing so we can
> >> apply it
> >> >> consistently everywhere" and I mentioned the situation of multiple
> >> acronyms
> >> >> in my first mail.
> >> >
> >> > At this point, our entire scope is what we have right now, and there
> >> > is no specific benefit to switching to 'acronyms as words' within that
> >> > scope. If the scope expands to those cases in the future, before a 1.0
> >> > release, we can revisit the issue.
> >> >
> >> > Thanks,
> >> >
> >> > Peter
> >>
> >>
> >>
> >> --
> >> Stian Soiland-Reyes
> >> Apache Taverna (incubating), Apache Commons RDF (incubating)
> >> http://orcid.org/0000-0001-9842-9718
> >>
>
Re: Casing: RdfTerm or RDFTerm?
Posted by Peter Ansell <an...@gmail.com>.
Hi Reto,
Sorry, but there is no real impetus for change. The status quo has to
be challenged for a change proposal of this nature, which it isn't
with only single acronyms in any of the classes we are working on
right now, even at this point with low change costs.
In addition, we are explicitly aiming not to be biased towards any of
the potential implementations, and your proposal is based solely on
fitting with your potential implementation.
Thanks,
Peter
On 23 March 2015 at 21:16, Reto Gmür <re...@apache.org> wrote:
> Right now we have negectable costs of changing, later it will mean an
> incompatible change.
>
> So while I'm fully aware that "Projects using the library make their own
> decisions", I nevertheless think that it is an advantage for Clerezza to
> use the same convention as what will be its most important library and most
> frequently used types.
>
> I suggest we have a vote and then stick to the decision.
>
> IIUC we have two proposals:
>
> a) Acronyms are treated like normal words, i.e. only the first character is
> uppercased, this is what the google style guide recommends
>
> d) If possible acronyms are cased as they appear in the specs (default
> casing), if they appear in a position where an uppercase first letter is
> required (and this letter is not uppercase in the default casing) then only
> this letter is uppercased, if they appear in a position where a lowercase
> first letter is required then the whole acronym is lowercased. Where
> obvious readability improvements result a different casing can be chosen.
>
> If I correctly described the proposals that have some support, we can have
> a vote on which one to pick.
>
> Cheers,
> Reto
>
>
>
>
>
> On Mon, Mar 23, 2015 at 9:57 AM, Stian Soiland-Reyes <st...@apache.org>
> wrote:
>
>> +1 - if we end up with say SPARQLRDFXMLSerializer (which would be out
>> of scope now!) then revisit - stay with current names for now.
>>
>> On 22 March 2015 at 20:56, Peter Ansell <an...@gmail.com> wrote:
>> > On 21 March 2015 at 20:25, Reto Gmür <re...@apache.org> wrote:
>> >>> You had then gone on to refer to the case of
>> >>> possibly having multiple acronyms, which we do not have.
>> >>>
>> >>
>> >> I started the discussion with the goal "to do the casing so we can
>> apply it
>> >> consistently everywhere" and I mentioned the situation of multiple
>> acronyms
>> >> in my first mail.
>> >
>> > At this point, our entire scope is what we have right now, and there
>> > is no specific benefit to switching to 'acronyms as words' within that
>> > scope. If the scope expands to those cases in the future, before a 1.0
>> > release, we can revisit the issue.
>> >
>> > Thanks,
>> >
>> > Peter
>>
>>
>>
>> --
>> Stian Soiland-Reyes
>> Apache Taverna (incubating), Apache Commons RDF (incubating)
>> http://orcid.org/0000-0001-9842-9718
>>
Re: Casing: RdfTerm or RDFTerm?
Posted by Reto Gmür <re...@apache.org>.
Right now we have negectable costs of changing, later it will mean an
incompatible change.
So while I'm fully aware that "Projects using the library make their own
decisions", I nevertheless think that it is an advantage for Clerezza to
use the same convention as what will be its most important library and most
frequently used types.
I suggest we have a vote and then stick to the decision.
IIUC we have two proposals:
a) Acronyms are treated like normal words, i.e. only the first character is
uppercased, this is what the google style guide recommends
d) If possible acronyms are cased as they appear in the specs (default
casing), if they appear in a position where an uppercase first letter is
required (and this letter is not uppercase in the default casing) then only
this letter is uppercased, if they appear in a position where a lowercase
first letter is required then the whole acronym is lowercased. Where
obvious readability improvements result a different casing can be chosen.
If I correctly described the proposals that have some support, we can have
a vote on which one to pick.
Cheers,
Reto
On Mon, Mar 23, 2015 at 9:57 AM, Stian Soiland-Reyes <st...@apache.org>
wrote:
> +1 - if we end up with say SPARQLRDFXMLSerializer (which would be out
> of scope now!) then revisit - stay with current names for now.
>
> On 22 March 2015 at 20:56, Peter Ansell <an...@gmail.com> wrote:
> > On 21 March 2015 at 20:25, Reto Gmür <re...@apache.org> wrote:
> >>> You had then gone on to refer to the case of
> >>> possibly having multiple acronyms, which we do not have.
> >>>
> >>
> >> I started the discussion with the goal "to do the casing so we can
> apply it
> >> consistently everywhere" and I mentioned the situation of multiple
> acronyms
> >> in my first mail.
> >
> > At this point, our entire scope is what we have right now, and there
> > is no specific benefit to switching to 'acronyms as words' within that
> > scope. If the scope expands to those cases in the future, before a 1.0
> > release, we can revisit the issue.
> >
> > Thanks,
> >
> > Peter
>
>
>
> --
> Stian Soiland-Reyes
> Apache Taverna (incubating), Apache Commons RDF (incubating)
> http://orcid.org/0000-0001-9842-9718
>
Re: Casing: RdfTerm or RDFTerm?
Posted by Stian Soiland-Reyes <st...@apache.org>.
+1 - if we end up with say SPARQLRDFXMLSerializer (which would be out
of scope now!) then revisit - stay with current names for now.
On 22 March 2015 at 20:56, Peter Ansell <an...@gmail.com> wrote:
> On 21 March 2015 at 20:25, Reto Gmür <re...@apache.org> wrote:
>>> You had then gone on to refer to the case of
>>> possibly having multiple acronyms, which we do not have.
>>>
>>
>> I started the discussion with the goal "to do the casing so we can apply it
>> consistently everywhere" and I mentioned the situation of multiple acronyms
>> in my first mail.
>
> At this point, our entire scope is what we have right now, and there
> is no specific benefit to switching to 'acronyms as words' within that
> scope. If the scope expands to those cases in the future, before a 1.0
> release, we can revisit the issue.
>
> Thanks,
>
> Peter
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: Casing: RdfTerm or RDFTerm?
Posted by Peter Ansell <an...@gmail.com>.
On 21 March 2015 at 20:25, Reto Gmür <re...@apache.org> wrote:
>> You had then gone on to refer to the case of
>> possibly having multiple acronyms, which we do not have.
>>
>
> I started the discussion with the goal "to do the casing so we can apply it
> consistently everywhere" and I mentioned the situation of multiple acronyms
> in my first mail.
At this point, our entire scope is what we have right now, and there
is no specific benefit to switching to 'acronyms as words' within that
scope. If the scope expands to those cases in the future, before a 1.0
release, we can revisit the issue.
Thanks,
Peter
Re: Casing: RdfTerm or RDFTerm?
Posted by Andy Seaborne <an...@apache.org>.
Reto - you misquote me.
> you and Andy a
> preference for having them uppercased,
Your initial summary (d) was closer. "cased as they appear in the
specs" ... within reason.
What naming conventions Clerezza has chosen is a matter for Clerezza.
Projects using the library make their own decisions.
Andy
On 21/03/15 09:25, Reto Gmür wrote:
> Hi Peter,
>
> It is true that an important argument for threating acronyms as word is
> based on the possibility of having multiple acronyms after each other. I
> don't think this argument becomes completely irrelevant just that right now
> we don't have such a type yet.
>
> No, we had already agreed that a single uppercase acronym in a class
>> name was acceptable.
>
>
> I don't see such an agreement:
>
> Gary and I expresses a preference for acronyms as words, you and Andy a
> preference for having them uppercased, Stian said he would vote 0.
>
>
>> You had then gone on to refer to the case of
>> possibly having multiple acronyms, which we do not have.
>>
>
> I started the discussion with the goal "to do the casing so we can apply it
> consistently everywhere" and I mentioned the situation of multiple acronyms
> in my first mail.
>
> We are free to choose whatever convention we want, or decide not have a
> convention. I'm very much in favor of having a convention also so that
> extending frameworks (like clerezza) can adopt it, and I have a preference
> for the "threat acronyms as words" convention.
>
> Reto
>
>
>>
>> On 21 March 2015 at 05:15, Reto Gmür <re...@apache.org> wrote:
>>> Sure: RDFTerm, IRI, BlankNodeOrIRI and RDFTermFactory
>>>
>>> Reto
>>>
>>> On Thu, Mar 19, 2015 at 9:38 PM, Peter Ansell <an...@gmail.com>
>>> wrote:
>>>
>>>> Hi Reto,
>>>>
>>>> Could you name the types that you are referring to? The image I am
>>>> looking at doesn't contain them:
>>>>
>>>>
>>>>
>> https://github.com/commons-rdf/commons-rdf/raw/master/api/src/main/resources/commons-rdf-class-diagram.png
>>>>
>>>> Thanks,
>>>>
>>>> Peter
>>>>
>>>> On 19 March 2015 at 22:47, Reto Gmür <re...@apache.org> wrote:
>>>>> Hi Peter
>>>>>
>>>>> In the clerezza version there are 3 and in the github version there
>> are 4
>>>>> types in the API that would have to be renamed. Additionally there are
>>>>> classes in the implementations that follow the same pattern.
>>>>>
>>>>> I can live with either version, and would probably even want to stick
>> to
>>>> it
>>>>> even when new acronyms are in use. I would like to have a decision so
>>>> that
>>>>> we either adapt the github code when importing it or we change the
>> code
>>>> at
>>>>> clerezza commons rdf.
>>>>>
>>>>> Cheers,
>>>>> Reto
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Mar 18, 2015 at 9:56 PM, Peter Ansell <ansell.peter@gmail.com
>>>
>>>>> wrote:
>>>>>
>>>>>> Hi Retro,
>>>>>>
>>>>>> In our case, there is only ever one acronym in a class name at this
>>>>>> point, so we should be fine with just uppercasing it without dealing
>>>>>> with the complexities you are referring to. If we ever find ourselves
>>>>>> in a position with multiple acronyms in a class name we can come back
>>>>>> to it.
>>>>>>
>>>>>> Cheers,
>>>>>>
>>>>>> Peter
>>>>>>
>>>>>> On 18 March 2015 at 19:22, Reto Gmür <re...@wymiwyg.com> wrote:
>>>>>>> I think the approach Andy suggested isn't in the three options of
>> my
>>>>>>> original mail. So let me try to paraphrase it:
>>>>>>>
>>>>>>> d) If possible acronyms are cased as they appear in the specs
>> (default
>>>>>>> casing), if they appear in a position where an uppercase first
>> letter
>>>> is
>>>>>>> required (and this letter is not uppercase in the default casing)
>> then
>>>>>> only
>>>>>>> this letter is uppercased, if they appear in a position where a
>>>> lowercase
>>>>>>> first letter is required then the whole acronym is lowercased.
>> Where
>>>>>>> obvious readability improvements result a different casing can be
>>>> chosen.
>>>>>>>
>>>>>>> So for example (with RDF, RDFa, sbt and iOS):
>>>>>>>
>>>>>>> RDFSbtPlugin - rdfSbtPlugin
>>>>>>> RDFaSbtPlugin - rdfaSbtPlugin
>>>>>>> IOSRDFTools - iOSRDFTools
>>>>>>>
>>>>>>> Is this the variant you Peter/Andy prefer?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Reto
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Mar 17, 2015 at 11:23 PM, Peter Ansell <
>>>> ansell.peter@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> +1, I prefer the current style and no clear reason why the other
>>>>>>>> possibility would be more beneficial for us at this point.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>>
>>>>>>>> Peter
>>>>>>>>
>>>>>>>> On 17 March 2015 at 22:27, Andy Seaborne <an...@apache.org> wrote:
>>>>>>>>> I prefer the current style. It's more common and closer to the
>>>> specs.
>>>>>>>>>
>>>>>>>>> Java itself uses SOAP*, SQL*, XPath*, JMX*, JAXB*, HTML*, ..
>> and a
>>>>>> mix of
>>>>>>>>> Xml and XML, Http and HTTP.
>>>>>>>>>
>>>>>>>>> (With deviation from any rules where obvious readability
>>>> improvements
>>>>>>>>> result.)
>>>>>>>>>
>>>>>>>>> Digressing - I found that an identifier of "_" now generates a
>>>>>> warning in
>>>>>>>>> Java8 (not that I would use a single _ much refer $) becaue ti's
>>>> going
>>>>>>>> to be
>>>>>>>>> removed. Anyone know the background to that? Scala alignment
>>>> maybe?
>>>>>>>>>
>>>>>>>>> Andy
>>>>>>>>>
>>>>>>>>> On 17/03/15 09:51, Reto Gmür wrote:
>>>>>>>>>>
>>>>>>>>>> I know it's just a detail and there is no clear right or wrong.
>>>> Still
>>>>>>>> I'd
>>>>>>>>>> like to have a conscious decision on how to do the casing so we
>>>> can
>>>>>>>> apply
>>>>>>>>>> it consistently everywhere.
>>>>>>>>>>
>>>>>>>>>> Approaches:
>>>>>>>>>> A) Acronyms are treated like normal words, i.e. only the first
>>>>>> character
>>>>>>>>>> is
>>>>>>>>>> uppercased, this is what the google style guide recommends [1]
>>>>>>>>>> B) Acronyms are uppercased as a whole
>>>>>>>>>> C) 2-Letter acronyms are uppercased, longer are treated like
>>>> normal
>>>>>>>> words
>>>>>>>>>> (this seems to be the .Net convention)
>>>>>>>>>>
>>>>>>>>>> I personally prefer the first approach for the following
>> reasons:
>>>>>>>>>> - IDEs get it right, the default name for the result of
>>>>>> getRdfUiApiKey()
>>>>>>>>>> or
>>>>>>>>>> a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or
>>>> apiKey,
>>>>>> or
>>>>>>>>>> key)
>>>>>>>>>> not rDFUIAPIKey.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Eclipse gets it right for any convention for me.
>>>>>>>>>
>>>>>>>>>> - It's more readable, the acronyms are the individual words,
>> the
>>>> case
>>>>>>>>>> distinctions allows to recognize them quickly
>>>>>>>>>> - It's not always obvious is something is an abbreviation or
>> any
>>>>>>>> acronym,
>>>>>>>>>> while it might seem OK to uppercase some abbreviations like
>> "OK"
>>>> or
>>>>>> "ID"
>>>>>>>>>> uppercasing other abreviations would look quite strange (e.g.
>>>>>>>>>> "LiteralIMPL"). So for consistency treat acronyms like
>>>> abbreviations
>>>>>>>> like
>>>>>>>>>> normal words.
>>>>>>>>>>
>>>>>>>>>> WDYT?
>>>>>>>>>
>>>>>>>>> ?Wdyt !
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Reto
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 1.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
>
Re: Casing: RdfTerm or RDFTerm?
Posted by Reto Gmür <re...@apache.org>.
Hi Peter,
It is true that an important argument for threating acronyms as word is
based on the possibility of having multiple acronyms after each other. I
don't think this argument becomes completely irrelevant just that right now
we don't have such a type yet.
No, we had already agreed that a single uppercase acronym in a class
> name was acceptable.
I don't see such an agreement:
Gary and I expresses a preference for acronyms as words, you and Andy a
preference for having them uppercased, Stian said he would vote 0.
> You had then gone on to refer to the case of
> possibly having multiple acronyms, which we do not have.
>
I started the discussion with the goal "to do the casing so we can apply it
consistently everywhere" and I mentioned the situation of multiple acronyms
in my first mail.
We are free to choose whatever convention we want, or decide not have a
convention. I'm very much in favor of having a convention also so that
extending frameworks (like clerezza) can adopt it, and I have a preference
for the "threat acronyms as words" convention.
Reto
>
> On 21 March 2015 at 05:15, Reto Gmür <re...@apache.org> wrote:
> > Sure: RDFTerm, IRI, BlankNodeOrIRI and RDFTermFactory
> >
> > Reto
> >
> > On Thu, Mar 19, 2015 at 9:38 PM, Peter Ansell <an...@gmail.com>
> > wrote:
> >
> >> Hi Reto,
> >>
> >> Could you name the types that you are referring to? The image I am
> >> looking at doesn't contain them:
> >>
> >>
> >>
> https://github.com/commons-rdf/commons-rdf/raw/master/api/src/main/resources/commons-rdf-class-diagram.png
> >>
> >> Thanks,
> >>
> >> Peter
> >>
> >> On 19 March 2015 at 22:47, Reto Gmür <re...@apache.org> wrote:
> >> > Hi Peter
> >> >
> >> > In the clerezza version there are 3 and in the github version there
> are 4
> >> > types in the API that would have to be renamed. Additionally there are
> >> > classes in the implementations that follow the same pattern.
> >> >
> >> > I can live with either version, and would probably even want to stick
> to
> >> it
> >> > even when new acronyms are in use. I would like to have a decision so
> >> that
> >> > we either adapt the github code when importing it or we change the
> code
> >> at
> >> > clerezza commons rdf.
> >> >
> >> > Cheers,
> >> > Reto
> >> >
> >> >
> >> >
> >> > On Wed, Mar 18, 2015 at 9:56 PM, Peter Ansell <ansell.peter@gmail.com
> >
> >> > wrote:
> >> >
> >> >> Hi Retro,
> >> >>
> >> >> In our case, there is only ever one acronym in a class name at this
> >> >> point, so we should be fine with just uppercasing it without dealing
> >> >> with the complexities you are referring to. If we ever find ourselves
> >> >> in a position with multiple acronyms in a class name we can come back
> >> >> to it.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Peter
> >> >>
> >> >> On 18 March 2015 at 19:22, Reto Gmür <re...@wymiwyg.com> wrote:
> >> >> > I think the approach Andy suggested isn't in the three options of
> my
> >> >> > original mail. So let me try to paraphrase it:
> >> >> >
> >> >> > d) If possible acronyms are cased as they appear in the specs
> (default
> >> >> > casing), if they appear in a position where an uppercase first
> letter
> >> is
> >> >> > required (and this letter is not uppercase in the default casing)
> then
> >> >> only
> >> >> > this letter is uppercased, if they appear in a position where a
> >> lowercase
> >> >> > first letter is required then the whole acronym is lowercased.
> Where
> >> >> > obvious readability improvements result a different casing can be
> >> chosen.
> >> >> >
> >> >> > So for example (with RDF, RDFa, sbt and iOS):
> >> >> >
> >> >> > RDFSbtPlugin - rdfSbtPlugin
> >> >> > RDFaSbtPlugin - rdfaSbtPlugin
> >> >> > IOSRDFTools - iOSRDFTools
> >> >> >
> >> >> > Is this the variant you Peter/Andy prefer?
> >> >> >
> >> >> > Cheers,
> >> >> > Reto
> >> >> >
> >> >> >
> >> >> >
> >> >> > On Tue, Mar 17, 2015 at 11:23 PM, Peter Ansell <
> >> ansell.peter@gmail.com>
> >> >> > wrote:
> >> >> >
> >> >> >> +1, I prefer the current style and no clear reason why the other
> >> >> >> possibility would be more beneficial for us at this point.
> >> >> >>
> >> >> >> Cheers,
> >> >> >>
> >> >> >> Peter
> >> >> >>
> >> >> >> On 17 March 2015 at 22:27, Andy Seaborne <an...@apache.org> wrote:
> >> >> >> > I prefer the current style. It's more common and closer to the
> >> specs.
> >> >> >> >
> >> >> >> > Java itself uses SOAP*, SQL*, XPath*, JMX*, JAXB*, HTML*, ..
> and a
> >> >> mix of
> >> >> >> > Xml and XML, Http and HTTP.
> >> >> >> >
> >> >> >> > (With deviation from any rules where obvious readability
> >> improvements
> >> >> >> > result.)
> >> >> >> >
> >> >> >> > Digressing - I found that an identifier of "_" now generates a
> >> >> warning in
> >> >> >> > Java8 (not that I would use a single _ much refer $) becaue ti's
> >> going
> >> >> >> to be
> >> >> >> > removed. Anyone know the background to that? Scala alignment
> >> maybe?
> >> >> >> >
> >> >> >> > Andy
> >> >> >> >
> >> >> >> > On 17/03/15 09:51, Reto Gmür wrote:
> >> >> >> >>
> >> >> >> >> I know it's just a detail and there is no clear right or wrong.
> >> Still
> >> >> >> I'd
> >> >> >> >> like to have a conscious decision on how to do the casing so we
> >> can
> >> >> >> apply
> >> >> >> >> it consistently everywhere.
> >> >> >> >>
> >> >> >> >> Approaches:
> >> >> >> >> A) Acronyms are treated like normal words, i.e. only the first
> >> >> character
> >> >> >> >> is
> >> >> >> >> uppercased, this is what the google style guide recommends [1]
> >> >> >> >> B) Acronyms are uppercased as a whole
> >> >> >> >> C) 2-Letter acronyms are uppercased, longer are treated like
> >> normal
> >> >> >> words
> >> >> >> >> (this seems to be the .Net convention)
> >> >> >> >>
> >> >> >> >> I personally prefer the first approach for the following
> reasons:
> >> >> >> >> - IDEs get it right, the default name for the result of
> >> >> getRdfUiApiKey()
> >> >> >> >> or
> >> >> >> >> a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or
> >> apiKey,
> >> >> or
> >> >> >> >> key)
> >> >> >> >> not rDFUIAPIKey.
> >> >> >> >
> >> >> >> >
> >> >> >> > Eclipse gets it right for any convention for me.
> >> >> >> >
> >> >> >> >> - It's more readable, the acronyms are the individual words,
> the
> >> case
> >> >> >> >> distinctions allows to recognize them quickly
> >> >> >> >> - It's not always obvious is something is an abbreviation or
> any
> >> >> >> acronym,
> >> >> >> >> while it might seem OK to uppercase some abbreviations like
> "OK"
> >> or
> >> >> "ID"
> >> >> >> >> uppercasing other abreviations would look quite strange (e.g.
> >> >> >> >> "LiteralIMPL"). So for consistency treat acronyms like
> >> abbreviations
> >> >> >> like
> >> >> >> >> normal words.
> >> >> >> >>
> >> >> >> >> WDYT?
> >> >> >> >
> >> >> >> > ?Wdyt !
> >> >> >> >
> >> >> >> >>
> >> >> >> >> Reto
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> 1.
> >> >> >> >>
> >> >> >> >>
> >> >> >>
> >> >>
> >>
> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
> >> >> >> >>
> >> >> >> >
> >> >> >>
> >> >>
> >>
>
Re: Casing: RdfTerm or RDFTerm?
Posted by Peter Ansell <an...@gmail.com>.
No, we had already agreed that a single uppercase acronym in a class
name was acceptable. You had then gone on to refer to the case of
possibly having multiple acronyms, which we do not have.
On 21 March 2015 at 05:15, Reto Gmür <re...@apache.org> wrote:
> Sure: RDFTerm, IRI, BlankNodeOrIRI and RDFTermFactory
>
> Reto
>
> On Thu, Mar 19, 2015 at 9:38 PM, Peter Ansell <an...@gmail.com>
> wrote:
>
>> Hi Reto,
>>
>> Could you name the types that you are referring to? The image I am
>> looking at doesn't contain them:
>>
>>
>> https://github.com/commons-rdf/commons-rdf/raw/master/api/src/main/resources/commons-rdf-class-diagram.png
>>
>> Thanks,
>>
>> Peter
>>
>> On 19 March 2015 at 22:47, Reto Gmür <re...@apache.org> wrote:
>> > Hi Peter
>> >
>> > In the clerezza version there are 3 and in the github version there are 4
>> > types in the API that would have to be renamed. Additionally there are
>> > classes in the implementations that follow the same pattern.
>> >
>> > I can live with either version, and would probably even want to stick to
>> it
>> > even when new acronyms are in use. I would like to have a decision so
>> that
>> > we either adapt the github code when importing it or we change the code
>> at
>> > clerezza commons rdf.
>> >
>> > Cheers,
>> > Reto
>> >
>> >
>> >
>> > On Wed, Mar 18, 2015 at 9:56 PM, Peter Ansell <an...@gmail.com>
>> > wrote:
>> >
>> >> Hi Retro,
>> >>
>> >> In our case, there is only ever one acronym in a class name at this
>> >> point, so we should be fine with just uppercasing it without dealing
>> >> with the complexities you are referring to. If we ever find ourselves
>> >> in a position with multiple acronyms in a class name we can come back
>> >> to it.
>> >>
>> >> Cheers,
>> >>
>> >> Peter
>> >>
>> >> On 18 March 2015 at 19:22, Reto Gmür <re...@wymiwyg.com> wrote:
>> >> > I think the approach Andy suggested isn't in the three options of my
>> >> > original mail. So let me try to paraphrase it:
>> >> >
>> >> > d) If possible acronyms are cased as they appear in the specs (default
>> >> > casing), if they appear in a position where an uppercase first letter
>> is
>> >> > required (and this letter is not uppercase in the default casing) then
>> >> only
>> >> > this letter is uppercased, if they appear in a position where a
>> lowercase
>> >> > first letter is required then the whole acronym is lowercased. Where
>> >> > obvious readability improvements result a different casing can be
>> chosen.
>> >> >
>> >> > So for example (with RDF, RDFa, sbt and iOS):
>> >> >
>> >> > RDFSbtPlugin - rdfSbtPlugin
>> >> > RDFaSbtPlugin - rdfaSbtPlugin
>> >> > IOSRDFTools - iOSRDFTools
>> >> >
>> >> > Is this the variant you Peter/Andy prefer?
>> >> >
>> >> > Cheers,
>> >> > Reto
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Mar 17, 2015 at 11:23 PM, Peter Ansell <
>> ansell.peter@gmail.com>
>> >> > wrote:
>> >> >
>> >> >> +1, I prefer the current style and no clear reason why the other
>> >> >> possibility would be more beneficial for us at this point.
>> >> >>
>> >> >> Cheers,
>> >> >>
>> >> >> Peter
>> >> >>
>> >> >> On 17 March 2015 at 22:27, Andy Seaborne <an...@apache.org> wrote:
>> >> >> > I prefer the current style. It's more common and closer to the
>> specs.
>> >> >> >
>> >> >> > Java itself uses SOAP*, SQL*, XPath*, JMX*, JAXB*, HTML*, .. and a
>> >> mix of
>> >> >> > Xml and XML, Http and HTTP.
>> >> >> >
>> >> >> > (With deviation from any rules where obvious readability
>> improvements
>> >> >> > result.)
>> >> >> >
>> >> >> > Digressing - I found that an identifier of "_" now generates a
>> >> warning in
>> >> >> > Java8 (not that I would use a single _ much refer $) becaue ti's
>> going
>> >> >> to be
>> >> >> > removed. Anyone know the background to that? Scala alignment
>> maybe?
>> >> >> >
>> >> >> > Andy
>> >> >> >
>> >> >> > On 17/03/15 09:51, Reto Gmür wrote:
>> >> >> >>
>> >> >> >> I know it's just a detail and there is no clear right or wrong.
>> Still
>> >> >> I'd
>> >> >> >> like to have a conscious decision on how to do the casing so we
>> can
>> >> >> apply
>> >> >> >> it consistently everywhere.
>> >> >> >>
>> >> >> >> Approaches:
>> >> >> >> A) Acronyms are treated like normal words, i.e. only the first
>> >> character
>> >> >> >> is
>> >> >> >> uppercased, this is what the google style guide recommends [1]
>> >> >> >> B) Acronyms are uppercased as a whole
>> >> >> >> C) 2-Letter acronyms are uppercased, longer are treated like
>> normal
>> >> >> words
>> >> >> >> (this seems to be the .Net convention)
>> >> >> >>
>> >> >> >> I personally prefer the first approach for the following reasons:
>> >> >> >> - IDEs get it right, the default name for the result of
>> >> getRdfUiApiKey()
>> >> >> >> or
>> >> >> >> a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or
>> apiKey,
>> >> or
>> >> >> >> key)
>> >> >> >> not rDFUIAPIKey.
>> >> >> >
>> >> >> >
>> >> >> > Eclipse gets it right for any convention for me.
>> >> >> >
>> >> >> >> - It's more readable, the acronyms are the individual words, the
>> case
>> >> >> >> distinctions allows to recognize them quickly
>> >> >> >> - It's not always obvious is something is an abbreviation or any
>> >> >> acronym,
>> >> >> >> while it might seem OK to uppercase some abbreviations like "OK"
>> or
>> >> "ID"
>> >> >> >> uppercasing other abreviations would look quite strange (e.g.
>> >> >> >> "LiteralIMPL"). So for consistency treat acronyms like
>> abbreviations
>> >> >> like
>> >> >> >> normal words.
>> >> >> >>
>> >> >> >> WDYT?
>> >> >> >
>> >> >> > ?Wdyt !
>> >> >> >
>> >> >> >>
>> >> >> >> Reto
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> 1.
>> >> >> >>
>> >> >> >>
>> >> >>
>> >>
>> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
>> >> >> >>
>> >> >> >
>> >> >>
>> >>
>>
Re: Casing: RdfTerm or RDFTerm?
Posted by Reto Gmür <re...@apache.org>.
Sure: RDFTerm, IRI, BlankNodeOrIRI and RDFTermFactory
Reto
On Thu, Mar 19, 2015 at 9:38 PM, Peter Ansell <an...@gmail.com>
wrote:
> Hi Reto,
>
> Could you name the types that you are referring to? The image I am
> looking at doesn't contain them:
>
>
> https://github.com/commons-rdf/commons-rdf/raw/master/api/src/main/resources/commons-rdf-class-diagram.png
>
> Thanks,
>
> Peter
>
> On 19 March 2015 at 22:47, Reto Gmür <re...@apache.org> wrote:
> > Hi Peter
> >
> > In the clerezza version there are 3 and in the github version there are 4
> > types in the API that would have to be renamed. Additionally there are
> > classes in the implementations that follow the same pattern.
> >
> > I can live with either version, and would probably even want to stick to
> it
> > even when new acronyms are in use. I would like to have a decision so
> that
> > we either adapt the github code when importing it or we change the code
> at
> > clerezza commons rdf.
> >
> > Cheers,
> > Reto
> >
> >
> >
> > On Wed, Mar 18, 2015 at 9:56 PM, Peter Ansell <an...@gmail.com>
> > wrote:
> >
> >> Hi Retro,
> >>
> >> In our case, there is only ever one acronym in a class name at this
> >> point, so we should be fine with just uppercasing it without dealing
> >> with the complexities you are referring to. If we ever find ourselves
> >> in a position with multiple acronyms in a class name we can come back
> >> to it.
> >>
> >> Cheers,
> >>
> >> Peter
> >>
> >> On 18 March 2015 at 19:22, Reto Gmür <re...@wymiwyg.com> wrote:
> >> > I think the approach Andy suggested isn't in the three options of my
> >> > original mail. So let me try to paraphrase it:
> >> >
> >> > d) If possible acronyms are cased as they appear in the specs (default
> >> > casing), if they appear in a position where an uppercase first letter
> is
> >> > required (and this letter is not uppercase in the default casing) then
> >> only
> >> > this letter is uppercased, if they appear in a position where a
> lowercase
> >> > first letter is required then the whole acronym is lowercased. Where
> >> > obvious readability improvements result a different casing can be
> chosen.
> >> >
> >> > So for example (with RDF, RDFa, sbt and iOS):
> >> >
> >> > RDFSbtPlugin - rdfSbtPlugin
> >> > RDFaSbtPlugin - rdfaSbtPlugin
> >> > IOSRDFTools - iOSRDFTools
> >> >
> >> > Is this the variant you Peter/Andy prefer?
> >> >
> >> > Cheers,
> >> > Reto
> >> >
> >> >
> >> >
> >> > On Tue, Mar 17, 2015 at 11:23 PM, Peter Ansell <
> ansell.peter@gmail.com>
> >> > wrote:
> >> >
> >> >> +1, I prefer the current style and no clear reason why the other
> >> >> possibility would be more beneficial for us at this point.
> >> >>
> >> >> Cheers,
> >> >>
> >> >> Peter
> >> >>
> >> >> On 17 March 2015 at 22:27, Andy Seaborne <an...@apache.org> wrote:
> >> >> > I prefer the current style. It's more common and closer to the
> specs.
> >> >> >
> >> >> > Java itself uses SOAP*, SQL*, XPath*, JMX*, JAXB*, HTML*, .. and a
> >> mix of
> >> >> > Xml and XML, Http and HTTP.
> >> >> >
> >> >> > (With deviation from any rules where obvious readability
> improvements
> >> >> > result.)
> >> >> >
> >> >> > Digressing - I found that an identifier of "_" now generates a
> >> warning in
> >> >> > Java8 (not that I would use a single _ much refer $) becaue ti's
> going
> >> >> to be
> >> >> > removed. Anyone know the background to that? Scala alignment
> maybe?
> >> >> >
> >> >> > Andy
> >> >> >
> >> >> > On 17/03/15 09:51, Reto Gmür wrote:
> >> >> >>
> >> >> >> I know it's just a detail and there is no clear right or wrong.
> Still
> >> >> I'd
> >> >> >> like to have a conscious decision on how to do the casing so we
> can
> >> >> apply
> >> >> >> it consistently everywhere.
> >> >> >>
> >> >> >> Approaches:
> >> >> >> A) Acronyms are treated like normal words, i.e. only the first
> >> character
> >> >> >> is
> >> >> >> uppercased, this is what the google style guide recommends [1]
> >> >> >> B) Acronyms are uppercased as a whole
> >> >> >> C) 2-Letter acronyms are uppercased, longer are treated like
> normal
> >> >> words
> >> >> >> (this seems to be the .Net convention)
> >> >> >>
> >> >> >> I personally prefer the first approach for the following reasons:
> >> >> >> - IDEs get it right, the default name for the result of
> >> getRdfUiApiKey()
> >> >> >> or
> >> >> >> a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or
> apiKey,
> >> or
> >> >> >> key)
> >> >> >> not rDFUIAPIKey.
> >> >> >
> >> >> >
> >> >> > Eclipse gets it right for any convention for me.
> >> >> >
> >> >> >> - It's more readable, the acronyms are the individual words, the
> case
> >> >> >> distinctions allows to recognize them quickly
> >> >> >> - It's not always obvious is something is an abbreviation or any
> >> >> acronym,
> >> >> >> while it might seem OK to uppercase some abbreviations like "OK"
> or
> >> "ID"
> >> >> >> uppercasing other abreviations would look quite strange (e.g.
> >> >> >> "LiteralIMPL"). So for consistency treat acronyms like
> abbreviations
> >> >> like
> >> >> >> normal words.
> >> >> >>
> >> >> >> WDYT?
> >> >> >
> >> >> > ?Wdyt !
> >> >> >
> >> >> >>
> >> >> >> Reto
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> 1.
> >> >> >>
> >> >> >>
> >> >>
> >>
> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
> >> >> >>
> >> >> >
> >> >>
> >>
>
Re: Casing: RdfTerm or RDFTerm?
Posted by Peter Ansell <an...@gmail.com>.
Hi Reto,
Could you name the types that you are referring to? The image I am
looking at doesn't contain them:
https://github.com/commons-rdf/commons-rdf/raw/master/api/src/main/resources/commons-rdf-class-diagram.png
Thanks,
Peter
On 19 March 2015 at 22:47, Reto Gmür <re...@apache.org> wrote:
> Hi Peter
>
> In the clerezza version there are 3 and in the github version there are 4
> types in the API that would have to be renamed. Additionally there are
> classes in the implementations that follow the same pattern.
>
> I can live with either version, and would probably even want to stick to it
> even when new acronyms are in use. I would like to have a decision so that
> we either adapt the github code when importing it or we change the code at
> clerezza commons rdf.
>
> Cheers,
> Reto
>
>
>
> On Wed, Mar 18, 2015 at 9:56 PM, Peter Ansell <an...@gmail.com>
> wrote:
>
>> Hi Retro,
>>
>> In our case, there is only ever one acronym in a class name at this
>> point, so we should be fine with just uppercasing it without dealing
>> with the complexities you are referring to. If we ever find ourselves
>> in a position with multiple acronyms in a class name we can come back
>> to it.
>>
>> Cheers,
>>
>> Peter
>>
>> On 18 March 2015 at 19:22, Reto Gmür <re...@wymiwyg.com> wrote:
>> > I think the approach Andy suggested isn't in the three options of my
>> > original mail. So let me try to paraphrase it:
>> >
>> > d) If possible acronyms are cased as they appear in the specs (default
>> > casing), if they appear in a position where an uppercase first letter is
>> > required (and this letter is not uppercase in the default casing) then
>> only
>> > this letter is uppercased, if they appear in a position where a lowercase
>> > first letter is required then the whole acronym is lowercased. Where
>> > obvious readability improvements result a different casing can be chosen.
>> >
>> > So for example (with RDF, RDFa, sbt and iOS):
>> >
>> > RDFSbtPlugin - rdfSbtPlugin
>> > RDFaSbtPlugin - rdfaSbtPlugin
>> > IOSRDFTools - iOSRDFTools
>> >
>> > Is this the variant you Peter/Andy prefer?
>> >
>> > Cheers,
>> > Reto
>> >
>> >
>> >
>> > On Tue, Mar 17, 2015 at 11:23 PM, Peter Ansell <an...@gmail.com>
>> > wrote:
>> >
>> >> +1, I prefer the current style and no clear reason why the other
>> >> possibility would be more beneficial for us at this point.
>> >>
>> >> Cheers,
>> >>
>> >> Peter
>> >>
>> >> On 17 March 2015 at 22:27, Andy Seaborne <an...@apache.org> wrote:
>> >> > I prefer the current style. It's more common and closer to the specs.
>> >> >
>> >> > Java itself uses SOAP*, SQL*, XPath*, JMX*, JAXB*, HTML*, .. and a
>> mix of
>> >> > Xml and XML, Http and HTTP.
>> >> >
>> >> > (With deviation from any rules where obvious readability improvements
>> >> > result.)
>> >> >
>> >> > Digressing - I found that an identifier of "_" now generates a
>> warning in
>> >> > Java8 (not that I would use a single _ much refer $) becaue ti's going
>> >> to be
>> >> > removed. Anyone know the background to that? Scala alignment maybe?
>> >> >
>> >> > Andy
>> >> >
>> >> > On 17/03/15 09:51, Reto Gmür wrote:
>> >> >>
>> >> >> I know it's just a detail and there is no clear right or wrong. Still
>> >> I'd
>> >> >> like to have a conscious decision on how to do the casing so we can
>> >> apply
>> >> >> it consistently everywhere.
>> >> >>
>> >> >> Approaches:
>> >> >> A) Acronyms are treated like normal words, i.e. only the first
>> character
>> >> >> is
>> >> >> uppercased, this is what the google style guide recommends [1]
>> >> >> B) Acronyms are uppercased as a whole
>> >> >> C) 2-Letter acronyms are uppercased, longer are treated like normal
>> >> words
>> >> >> (this seems to be the .Net convention)
>> >> >>
>> >> >> I personally prefer the first approach for the following reasons:
>> >> >> - IDEs get it right, the default name for the result of
>> getRdfUiApiKey()
>> >> >> or
>> >> >> a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or apiKey,
>> or
>> >> >> key)
>> >> >> not rDFUIAPIKey.
>> >> >
>> >> >
>> >> > Eclipse gets it right for any convention for me.
>> >> >
>> >> >> - It's more readable, the acronyms are the individual words, the case
>> >> >> distinctions allows to recognize them quickly
>> >> >> - It's not always obvious is something is an abbreviation or any
>> >> acronym,
>> >> >> while it might seem OK to uppercase some abbreviations like "OK" or
>> "ID"
>> >> >> uppercasing other abreviations would look quite strange (e.g.
>> >> >> "LiteralIMPL"). So for consistency treat acronyms like abbreviations
>> >> like
>> >> >> normal words.
>> >> >>
>> >> >> WDYT?
>> >> >
>> >> > ?Wdyt !
>> >> >
>> >> >>
>> >> >> Reto
>> >> >>
>> >> >>
>> >> >>
>> >> >> 1.
>> >> >>
>> >> >>
>> >>
>> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
>> >> >>
>> >> >
>> >>
>>
Re: Casing: RdfTerm or RDFTerm?
Posted by Reto Gmür <re...@apache.org>.
Hi Peter
In the clerezza version there are 3 and in the github version there are 4
types in the API that would have to be renamed. Additionally there are
classes in the implementations that follow the same pattern.
I can live with either version, and would probably even want to stick to it
even when new acronyms are in use. I would like to have a decision so that
we either adapt the github code when importing it or we change the code at
clerezza commons rdf.
Cheers,
Reto
On Wed, Mar 18, 2015 at 9:56 PM, Peter Ansell <an...@gmail.com>
wrote:
> Hi Retro,
>
> In our case, there is only ever one acronym in a class name at this
> point, so we should be fine with just uppercasing it without dealing
> with the complexities you are referring to. If we ever find ourselves
> in a position with multiple acronyms in a class name we can come back
> to it.
>
> Cheers,
>
> Peter
>
> On 18 March 2015 at 19:22, Reto Gmür <re...@wymiwyg.com> wrote:
> > I think the approach Andy suggested isn't in the three options of my
> > original mail. So let me try to paraphrase it:
> >
> > d) If possible acronyms are cased as they appear in the specs (default
> > casing), if they appear in a position where an uppercase first letter is
> > required (and this letter is not uppercase in the default casing) then
> only
> > this letter is uppercased, if they appear in a position where a lowercase
> > first letter is required then the whole acronym is lowercased. Where
> > obvious readability improvements result a different casing can be chosen.
> >
> > So for example (with RDF, RDFa, sbt and iOS):
> >
> > RDFSbtPlugin - rdfSbtPlugin
> > RDFaSbtPlugin - rdfaSbtPlugin
> > IOSRDFTools - iOSRDFTools
> >
> > Is this the variant you Peter/Andy prefer?
> >
> > Cheers,
> > Reto
> >
> >
> >
> > On Tue, Mar 17, 2015 at 11:23 PM, Peter Ansell <an...@gmail.com>
> > wrote:
> >
> >> +1, I prefer the current style and no clear reason why the other
> >> possibility would be more beneficial for us at this point.
> >>
> >> Cheers,
> >>
> >> Peter
> >>
> >> On 17 March 2015 at 22:27, Andy Seaborne <an...@apache.org> wrote:
> >> > I prefer the current style. It's more common and closer to the specs.
> >> >
> >> > Java itself uses SOAP*, SQL*, XPath*, JMX*, JAXB*, HTML*, .. and a
> mix of
> >> > Xml and XML, Http and HTTP.
> >> >
> >> > (With deviation from any rules where obvious readability improvements
> >> > result.)
> >> >
> >> > Digressing - I found that an identifier of "_" now generates a
> warning in
> >> > Java8 (not that I would use a single _ much refer $) becaue ti's going
> >> to be
> >> > removed. Anyone know the background to that? Scala alignment maybe?
> >> >
> >> > Andy
> >> >
> >> > On 17/03/15 09:51, Reto Gmür wrote:
> >> >>
> >> >> I know it's just a detail and there is no clear right or wrong. Still
> >> I'd
> >> >> like to have a conscious decision on how to do the casing so we can
> >> apply
> >> >> it consistently everywhere.
> >> >>
> >> >> Approaches:
> >> >> A) Acronyms are treated like normal words, i.e. only the first
> character
> >> >> is
> >> >> uppercased, this is what the google style guide recommends [1]
> >> >> B) Acronyms are uppercased as a whole
> >> >> C) 2-Letter acronyms are uppercased, longer are treated like normal
> >> words
> >> >> (this seems to be the .Net convention)
> >> >>
> >> >> I personally prefer the first approach for the following reasons:
> >> >> - IDEs get it right, the default name for the result of
> getRdfUiApiKey()
> >> >> or
> >> >> a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or apiKey,
> or
> >> >> key)
> >> >> not rDFUIAPIKey.
> >> >
> >> >
> >> > Eclipse gets it right for any convention for me.
> >> >
> >> >> - It's more readable, the acronyms are the individual words, the case
> >> >> distinctions allows to recognize them quickly
> >> >> - It's not always obvious is something is an abbreviation or any
> >> acronym,
> >> >> while it might seem OK to uppercase some abbreviations like "OK" or
> "ID"
> >> >> uppercasing other abreviations would look quite strange (e.g.
> >> >> "LiteralIMPL"). So for consistency treat acronyms like abbreviations
> >> like
> >> >> normal words.
> >> >>
> >> >> WDYT?
> >> >
> >> > ?Wdyt !
> >> >
> >> >>
> >> >> Reto
> >> >>
> >> >>
> >> >>
> >> >> 1.
> >> >>
> >> >>
> >>
> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
> >> >>
> >> >
> >>
>
Re: Casing: RdfTerm or RDFTerm?
Posted by Peter Ansell <an...@gmail.com>.
Hi Retro,
In our case, there is only ever one acronym in a class name at this
point, so we should be fine with just uppercasing it without dealing
with the complexities you are referring to. If we ever find ourselves
in a position with multiple acronyms in a class name we can come back
to it.
Cheers,
Peter
On 18 March 2015 at 19:22, Reto Gmür <re...@wymiwyg.com> wrote:
> I think the approach Andy suggested isn't in the three options of my
> original mail. So let me try to paraphrase it:
>
> d) If possible acronyms are cased as they appear in the specs (default
> casing), if they appear in a position where an uppercase first letter is
> required (and this letter is not uppercase in the default casing) then only
> this letter is uppercased, if they appear in a position where a lowercase
> first letter is required then the whole acronym is lowercased. Where
> obvious readability improvements result a different casing can be chosen.
>
> So for example (with RDF, RDFa, sbt and iOS):
>
> RDFSbtPlugin - rdfSbtPlugin
> RDFaSbtPlugin - rdfaSbtPlugin
> IOSRDFTools - iOSRDFTools
>
> Is this the variant you Peter/Andy prefer?
>
> Cheers,
> Reto
>
>
>
> On Tue, Mar 17, 2015 at 11:23 PM, Peter Ansell <an...@gmail.com>
> wrote:
>
>> +1, I prefer the current style and no clear reason why the other
>> possibility would be more beneficial for us at this point.
>>
>> Cheers,
>>
>> Peter
>>
>> On 17 March 2015 at 22:27, Andy Seaborne <an...@apache.org> wrote:
>> > I prefer the current style. It's more common and closer to the specs.
>> >
>> > Java itself uses SOAP*, SQL*, XPath*, JMX*, JAXB*, HTML*, .. and a mix of
>> > Xml and XML, Http and HTTP.
>> >
>> > (With deviation from any rules where obvious readability improvements
>> > result.)
>> >
>> > Digressing - I found that an identifier of "_" now generates a warning in
>> > Java8 (not that I would use a single _ much refer $) becaue ti's going
>> to be
>> > removed. Anyone know the background to that? Scala alignment maybe?
>> >
>> > Andy
>> >
>> > On 17/03/15 09:51, Reto Gmür wrote:
>> >>
>> >> I know it's just a detail and there is no clear right or wrong. Still
>> I'd
>> >> like to have a conscious decision on how to do the casing so we can
>> apply
>> >> it consistently everywhere.
>> >>
>> >> Approaches:
>> >> A) Acronyms are treated like normal words, i.e. only the first character
>> >> is
>> >> uppercased, this is what the google style guide recommends [1]
>> >> B) Acronyms are uppercased as a whole
>> >> C) 2-Letter acronyms are uppercased, longer are treated like normal
>> words
>> >> (this seems to be the .Net convention)
>> >>
>> >> I personally prefer the first approach for the following reasons:
>> >> - IDEs get it right, the default name for the result of getRdfUiApiKey()
>> >> or
>> >> a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or apiKey, or
>> >> key)
>> >> not rDFUIAPIKey.
>> >
>> >
>> > Eclipse gets it right for any convention for me.
>> >
>> >> - It's more readable, the acronyms are the individual words, the case
>> >> distinctions allows to recognize them quickly
>> >> - It's not always obvious is something is an abbreviation or any
>> acronym,
>> >> while it might seem OK to uppercase some abbreviations like "OK" or "ID"
>> >> uppercasing other abreviations would look quite strange (e.g.
>> >> "LiteralIMPL"). So for consistency treat acronyms like abbreviations
>> like
>> >> normal words.
>> >>
>> >> WDYT?
>> >
>> > ?Wdyt !
>> >
>> >>
>> >> Reto
>> >>
>> >>
>> >>
>> >> 1.
>> >>
>> >>
>> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
>> >>
>> >
>>
Re: Casing: RdfTerm or RDFTerm?
Posted by Reto Gmür <re...@wymiwyg.com>.
I think the approach Andy suggested isn't in the three options of my
original mail. So let me try to paraphrase it:
d) If possible acronyms are cased as they appear in the specs (default
casing), if they appear in a position where an uppercase first letter is
required (and this letter is not uppercase in the default casing) then only
this letter is uppercased, if they appear in a position where a lowercase
first letter is required then the whole acronym is lowercased. Where
obvious readability improvements result a different casing can be chosen.
So for example (with RDF, RDFa, sbt and iOS):
RDFSbtPlugin - rdfSbtPlugin
RDFaSbtPlugin - rdfaSbtPlugin
IOSRDFTools - iOSRDFTools
Is this the variant you Peter/Andy prefer?
Cheers,
Reto
On Tue, Mar 17, 2015 at 11:23 PM, Peter Ansell <an...@gmail.com>
wrote:
> +1, I prefer the current style and no clear reason why the other
> possibility would be more beneficial for us at this point.
>
> Cheers,
>
> Peter
>
> On 17 March 2015 at 22:27, Andy Seaborne <an...@apache.org> wrote:
> > I prefer the current style. It's more common and closer to the specs.
> >
> > Java itself uses SOAP*, SQL*, XPath*, JMX*, JAXB*, HTML*, .. and a mix of
> > Xml and XML, Http and HTTP.
> >
> > (With deviation from any rules where obvious readability improvements
> > result.)
> >
> > Digressing - I found that an identifier of "_" now generates a warning in
> > Java8 (not that I would use a single _ much refer $) becaue ti's going
> to be
> > removed. Anyone know the background to that? Scala alignment maybe?
> >
> > Andy
> >
> > On 17/03/15 09:51, Reto Gmür wrote:
> >>
> >> I know it's just a detail and there is no clear right or wrong. Still
> I'd
> >> like to have a conscious decision on how to do the casing so we can
> apply
> >> it consistently everywhere.
> >>
> >> Approaches:
> >> A) Acronyms are treated like normal words, i.e. only the first character
> >> is
> >> uppercased, this is what the google style guide recommends [1]
> >> B) Acronyms are uppercased as a whole
> >> C) 2-Letter acronyms are uppercased, longer are treated like normal
> words
> >> (this seems to be the .Net convention)
> >>
> >> I personally prefer the first approach for the following reasons:
> >> - IDEs get it right, the default name for the result of getRdfUiApiKey()
> >> or
> >> a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or apiKey, or
> >> key)
> >> not rDFUIAPIKey.
> >
> >
> > Eclipse gets it right for any convention for me.
> >
> >> - It's more readable, the acronyms are the individual words, the case
> >> distinctions allows to recognize them quickly
> >> - It's not always obvious is something is an abbreviation or any
> acronym,
> >> while it might seem OK to uppercase some abbreviations like "OK" or "ID"
> >> uppercasing other abreviations would look quite strange (e.g.
> >> "LiteralIMPL"). So for consistency treat acronyms like abbreviations
> like
> >> normal words.
> >>
> >> WDYT?
> >
> > ?Wdyt !
> >
> >>
> >> Reto
> >>
> >>
> >>
> >> 1.
> >>
> >>
> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
> >>
> >
>
Re: Casing: RdfTerm or RDFTerm?
Posted by Peter Ansell <an...@gmail.com>.
+1, I prefer the current style and no clear reason why the other
possibility would be more beneficial for us at this point.
Cheers,
Peter
On 17 March 2015 at 22:27, Andy Seaborne <an...@apache.org> wrote:
> I prefer the current style. It's more common and closer to the specs.
>
> Java itself uses SOAP*, SQL*, XPath*, JMX*, JAXB*, HTML*, .. and a mix of
> Xml and XML, Http and HTTP.
>
> (With deviation from any rules where obvious readability improvements
> result.)
>
> Digressing - I found that an identifier of "_" now generates a warning in
> Java8 (not that I would use a single _ much refer $) becaue ti's going to be
> removed. Anyone know the background to that? Scala alignment maybe?
>
> Andy
>
> On 17/03/15 09:51, Reto Gmür wrote:
>>
>> I know it's just a detail and there is no clear right or wrong. Still I'd
>> like to have a conscious decision on how to do the casing so we can apply
>> it consistently everywhere.
>>
>> Approaches:
>> A) Acronyms are treated like normal words, i.e. only the first character
>> is
>> uppercased, this is what the google style guide recommends [1]
>> B) Acronyms are uppercased as a whole
>> C) 2-Letter acronyms are uppercased, longer are treated like normal words
>> (this seems to be the .Net convention)
>>
>> I personally prefer the first approach for the following reasons:
>> - IDEs get it right, the default name for the result of getRdfUiApiKey()
>> or
>> a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or apiKey, or
>> key)
>> not rDFUIAPIKey.
>
>
> Eclipse gets it right for any convention for me.
>
>> - It's more readable, the acronyms are the individual words, the case
>> distinctions allows to recognize them quickly
>> - It's not always obvious is something is an abbreviation or any acronym,
>> while it might seem OK to uppercase some abbreviations like "OK" or "ID"
>> uppercasing other abreviations would look quite strange (e.g.
>> "LiteralIMPL"). So for consistency treat acronyms like abbreviations like
>> normal words.
>>
>> WDYT?
>
> ?Wdyt !
>
>>
>> Reto
>>
>>
>>
>> 1.
>>
>> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
>>
>
Re: Casing: RdfTerm or RDFTerm?
Posted by Andy Seaborne <an...@apache.org>.
I prefer the current style. It's more common and closer to the specs.
Java itself uses SOAP*, SQL*, XPath*, JMX*, JAXB*, HTML*, .. and a mix
of Xml and XML, Http and HTTP.
(With deviation from any rules where obvious readability improvements
result.)
Digressing - I found that an identifier of "_" now generates a warning
in Java8 (not that I would use a single _ much refer $) becaue ti's
going to be removed. Anyone know the background to that? Scala
alignment maybe?
Andy
On 17/03/15 09:51, Reto Gmür wrote:
> I know it's just a detail and there is no clear right or wrong. Still I'd
> like to have a conscious decision on how to do the casing so we can apply
> it consistently everywhere.
>
> Approaches:
> A) Acronyms are treated like normal words, i.e. only the first character is
> uppercased, this is what the google style guide recommends [1]
> B) Acronyms are uppercased as a whole
> C) 2-Letter acronyms are uppercased, longer are treated like normal words
> (this seems to be the .Net convention)
>
> I personally prefer the first approach for the following reasons:
> - IDEs get it right, the default name for the result of getRdfUiApiKey() or
> a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or apiKey, or key)
> not rDFUIAPIKey.
Eclipse gets it right for any convention for me.
> - It's more readable, the acronyms are the individual words, the case
> distinctions allows to recognize them quickly
> - It's not always obvious is something is an abbreviation or any acronym,
> while it might seem OK to uppercase some abbreviations like "OK" or "ID"
> uppercasing other abreviations would look quite strange (e.g.
> "LiteralIMPL"). So for consistency treat acronyms like abbreviations like
> normal words.
>
> WDYT?
?Wdyt !
>
> Reto
>
>
>
> 1.
> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
>
Re: Casing: RdfTerm or RDFTerm?
Posted by Stian Soiland-Reyes <st...@apache.org>.
I'm never quite decided on those.. I struggle with JsonThing vs
JSONThing. One advantage of the first style is that it autocompletes
much nicer, I don't have to type out the full acronym before I can
type the T for Thing (e.g. J T Ctrl-Shift-T). Also it downplays the
importance of the acronym.
getJpegViewer() vs getJPEGViewer() -- I would pick the first one.
class ConvertJSON2RDF -- NO! WHAT IS GOIG ON HERE?!?
class ConvertJsonToRdf wins.
but..
RdfTerm vs RDFTerm ... here I actually prefer "RDFTerm" though - as
"Rdf" can't be read like a word ("urduff"?), unlike "Jay-pegg" and
"Jason".
Sorry for not being more conclusive .. :) I would vote 0 for either.
On 17 March 2015 at 09:51, Reto Gmür <re...@apache.org> wrote:
> I know it's just a detail and there is no clear right or wrong. Still I'd
> like to have a conscious decision on how to do the casing so we can apply
> it consistently everywhere.
>
> Approaches:
> A) Acronyms are treated like normal words, i.e. only the first character is
> uppercased, this is what the google style guide recommends [1]
> B) Acronyms are uppercased as a whole
> C) 2-Letter acronyms are uppercased, longer are treated like normal words
> (this seems to be the .Net convention)
>
> I personally prefer the first approach for the following reasons:
> - IDEs get it right, the default name for the result of getRdfUiApiKey() or
> a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or apiKey, or key)
> not rDFUIAPIKey.
> - It's more readable, the acronyms are the individual words, the case
> distinctions allows to recognize them quickly
> - It's not always obvious is something is an abbreviation or any acronym,
> while it might seem OK to uppercase some abbreviations like "OK" or "ID"
> uppercasing other abreviations would look quite strange (e.g.
> "LiteralIMPL"). So for consistency treat acronyms like abbreviations like
> normal words.
>
> WDYT?
>
> Reto
>
>
>
> 1.
> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
--
Stian Soiland-Reyes
Apache Taverna (incubating), Apache Commons RDF (incubating)
http://orcid.org/0000-0001-9842-9718
Re: Casing: RdfTerm or RDFTerm?
Posted by Gary Gregory <ga...@gmail.com>.
+1 for Acronyms as word. I never want to see another XMLSAXDTDParser type
of name...
Gary
On Tue, Mar 17, 2015 at 2:51 AM, Reto Gmür <re...@apache.org> wrote:
> I know it's just a detail and there is no clear right or wrong. Still I'd
> like to have a conscious decision on how to do the casing so we can apply
> it consistently everywhere.
>
> Approaches:
> A) Acronyms are treated like normal words, i.e. only the first character is
> uppercased, this is what the google style guide recommends [1]
> B) Acronyms are uppercased as a whole
> C) 2-Letter acronyms are uppercased, longer are treated like normal words
> (this seems to be the .Net convention)
>
> I personally prefer the first approach for the following reasons:
> - IDEs get it right, the default name for the result of getRdfUiApiKey() or
> a field of type RdfUiApiKey is rdfUiApiKey (or uiApiKey, or apiKey, or key)
> not rDFUIAPIKey.
> - It's more readable, the acronyms are the individual words, the case
> distinctions allows to recognize them quickly
> - It's not always obvious is something is an abbreviation or any acronym,
> while it might seem OK to uppercase some abbreviations like "OK" or "ID"
> uppercasing other abreviations would look quite strange (e.g.
> "LiteralIMPL"). So for consistency treat acronyms like abbreviations like
> normal words.
>
> WDYT?
>
> Reto
>
>
>
> 1.
>
> https://google-styleguide.googlecode.com/svn/trunk/javaguide.html#s5.3-camel-case
>
--
E-Mail: garydgregory@gmail.com | ggregory@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