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 <r...@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 <ansell.pe...@gmail.com> wrote: > >> > On 21 March 2015 at 20:25, Reto Gmür <r...@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 > >> >
