On Fri, Mar 27, 2015 at 9:04 AM, Andy Seaborne <a...@apache.org> wrote:
> On 27/03/15 07:41, Reto Gmür wrote: > >> Hi Peter, >> >> Does it make sense to have two (apache) projects with the first goal of >> providing an API modeling the W3C RDF standard? >> > > I don't understand the point about "first goal". What's the thinking > behind that? > The first and foremost feature (as per the project proposals). Reto > > Andy > > > It may very well make sense, say if one API is more like DOM and the other >> is more like SAX and there can be tons of other reasons why there is a >> justification for two APIs maintained by two communities. However I think >> that if the difference if that one uses lowercase chars and the other use >> uppercase chars is a very poor reason to justify two different APIs. So >> what's the problem taking a majority decision to have a defined casing >> convention? If your main concern is not to have the same convention as any >> other API you can propose a iNVERSEcAMELcASE. >> >> Cheers, >> Reto >> >> On Thu, Mar 26, 2015 at 11:03 PM, Peter Ansell <ansell.pe...@gmail.com> >> wrote: >> >> Hi Reto, >>> >>> I think you have misunderstood a little the way that we have been >>> approaching your implementation. We have not been approaching this >>> project with the idea of integrating any of the content from any of >>> the implementations, including Clerezza. We want to support an API >>> that different implementations can use, but we have no interest in >>> merging projects or historical codebases into the API that we are >>> building from scratch. Ie, we are not aiming to converge the Clerezza >>> and Commons RDF projects at all and I don't think anyone has brought >>> this idea up other than you. >>> >>> Being inside of the Apache program does not make Clerezza in any way >>> more important than any of the other Apache or non-Apache JVM projects >>> that have a relationship to RDF, per our goals to be both >>> implementation and vendor independent. >>> >>> Thanks, >>> >>> Peter >>> >>> On 27 March 2015 at 04:13, Reto Gmür <r...@apache.org> wrote: >>> >>>> Hi Rob, >>>> >>>> Just from code one cannot deduct the convention behind it, there are in >>>> theory infinite different conventions resulting in the same result. One >>>> >>> of >>> >>>> the two variants in the vote is a convention that yields to the results >>>> >>> as >>> >>>> in the code currently in github and bases on Andy's remarks in the >>>> discussion thread. >>>> >>>> As a person active in both apache projects that aim to produce a vendor >>>> independent RDF API (clerezza, and incubating commons RDF) I aim for >>>> convergence of the two API projects. At Clerezza we plan a release of >>>> refactored core library that get closer (for now mainly in naming) to >>>> the >>>> classes in the github proposal. >>>> >>>> Now I am NOT saying that convergence needs adaptation on both sides, if >>>> what results from this project satisfies the technical requirements of >>>> clerezza then it shall replace the clerezza API. But if the two APIs >>>> >>> shall >>> >>>> evolve into one, even if it's just the clerezza API directing its >>>> >>> evolution >>> >>>> at least the direction should be known. >>>> >>>> I'm saying "we can meet in uppecase land or in lowercase land, let's >>>> discuss what's better and choose", the answer is "right now we are >>>> somewhere in uppercase land we don't tell you were exactly and we might >>>> change it later". >>>> >>>> With Clerezza hat on I'm saying: "Tell us the convention you are using, >>>> >>> so >>> >>>> we can follow it resulting in the same method and class names for what >>>> we >>>> have in common". >>>> >>>> With the PPMC hat on I'm saying: "Let's choose the best and most >>>> sustainable convention as early as possible". >>>> >>>> If the current code follows a convention (as you understand) then why >>>> not >>>> make this explicit? Not voting on the convention doesn't make things >>>> >>> better >>> >>>> for but worse, because having an explicit convention is much better than >>>> just some code that is defended against changes. It cannot be the apache >>>> way to produce faits accomplis outside apache and then rush for a first >>>> release in the incubator. >>>> >>>> Cheers, >>>> Reto >>>> >>>> On Wed, Mar 25, 2015 at 12:30 PM, Rob Vesse <rve...@dotnetrdf.org> >>>> >>> wrote: >>> >>>> >>>> My understanding from the thread was that the current code base does >>>>> follow a convention (if not anyones preferred convention) and thus >>>>> >>>> several >>> >>>> people have suggested that no change is necessary >>>>> >>>>> Lack of consensus is not a reason to force a decision via a vote. >>>>> >>>> Winners >>> >>>> and losers affects the health of community because some community >>>>> >>>> members >>> >>>> may feel aggrieved (whether rightly/wrongly) and this may manifest in >>>>> various ways depending on the individuals and affect the community in >>>>> >>>> the >>> >>>> long run >>>>> >>>>> If a decision is important then it should be possible to reach some >>>>> consensus eventually even if the decision is contentious. If the >>>>> >>>> decision >>> >>>> is unimportant and there is no consensus around it then there is no >>>>> >>>> reason >>> >>>> to force a change for the sake of it >>>>> >>>>> Rob >>>>> >>>>> On 25/03/2015 11:19, "Reto Gmür" <r...@apache.org> wrote: >>>>> >>>>> Hi Rob, >>>>>> >>>>>> It is true that there is no consensus in the community. Will there be >>>>>> a >>>>>> consensus? I doubt it and I regard the decision an unimportant enough >>>>>> >>>>> that >>> >>>> I hope everybody can live with either decision. So while technically >>>>>> >>>>> we >>> >>>> have winners and losers, I don't see how this affects the health of the >>>>>> community. >>>>>> >>>>>> For me, more important than having my preferred casing option is to >>>>>> >>>>> have >>> >>>> an >>>>>> agreed convention. So I prefer being a "loser" in that vote rather >>>>>> than >>>>>> having no decision at all. >>>>>> >>>>>> Your concern would be very justified, if there would be an ongoing >>>>>> development that could lead to a consensus making the majority vote >>>>>> obsolete. I however don't think anybody thinks we go on presenting >>>>>> arguments and considerations. So I think the vote is an effective way >>>>>> >>>>> to >>> >>>> end this potato-potatoe discussion. >>>>>> >>>>>> Cheers, >>>>>> Reto >>>>>> >>>>>> On Wed, Mar 25, 2015 at 9:37 AM, Rob Vesse <rve...@dotnetrdf.org> >>>>>> >>>>> wrote: >>> >>>> >>>>>> /Mentor Hat On >>>>>>> >>>>>>> I strongly recommend against calling votes like the one below where >>>>>>> there >>>>>>> is clearly no consensus in the community >>>>>>> >>>>>>> If you've been following the recent thread on dev@community.a.o >>>>>>> >>>>>> about >>> >>>> vetoes and votes much of the discussion centres around the fact that >>>>>>> using >>>>>>> a vote to force a decision does not make for a healthy community >>>>>>> >>>>>> since >>> >>>> it >>>>>>> creates winners and losers >>>>>>> >>>>>>> http://s.apache.org/dev-veto-thread >>>>>>> >>>>>>> >>>>>>> Where there is no consensus asking for a vote only furthers the >>>>>>> >>>>>> existing >>> >>>> disagreements >>>>>>> >>>>>>> The podling should be focusing on actual progress such as IP >>>>>>> >>>>>> clearance, >>> >>>> finishing migration into the Incubator and getting a first release >>>>>>> prepared >>>>>>> >>>>>>> Rob >>>>>>> >>>>>>> On 24/03/2015 22:07, "Reto Gmür" <r...@apache.org> wrote: >>>>>>> >>>>>>> >From the discussion thread "Casing: RdfTerm or RDFTerm" [1] there >>>>>>> >>>>>> were >>> >>>> two >>>>>>> >>>>>>>> possible casing conventions for acronyms that found some support. I >>>>>>>> >>>>>>> would >>>>>>> >>>>>>>> like thus to call for a vote to determine the preference of the >>>>>>>> >>>>>>> PPMC. >>> >>>> >>>>>>>> Variant 1: >>>>>>>> Acronyms are treated like normal words, i.e. only the first >>>>>>>> >>>>>>> character >>> >>>> is >>>>>>> >>>>>>>> uppercased. >>>>>>>> >>>>>>>> Variant 2: >>>>>>>> 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. >>>>>>> >>>>>>>> >>>>>>>> Please indicate your preference: >>>>>>>> >>>>>>>> [ ] I prefer variant 1 >>>>>>>> [ ] I prefer variant 2 >>>>>>>> [ ] I oppose to both >>>>>>>> >>>>>>>> The winning variant shall be voted for acceptance in a binary >>>>>>>> >>>>>>> yes/no >>> >>>> vote. >>>>>>>> This step can be skipped if a variant has a majority of the votes >>>>>>>> >>>>>>> already >>>>>>> >>>>>>>> and nobody asks for the additional vote. >>>>>>>> >>>>>>>> The vote is open for 72 hours. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Reto >>>>>>>> >>>>>>>> >>>>>>>> 1. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> http://mail-archives.apache.org/mod_mbox/incubator- >>> commonsrdf-dev/201503 >>> >>>> . >>>>> >>>>>> m >>>>>>> >>>>>>>> box/%3CCALvhUEUg5_xvkYJPUPBhtmbbYT2ns1XoHXrNZhd64od6h48jvA% >>>>>>>> >>>>>>> 40mail.gmail.co >>>>>>> >>>>>>>> m%3E >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >> >
