Hi Benedikt, I agree that building an actual consensus, ie, full (~100%) consensus, not just a democratic majority (>50%) consensus, could still be used to change some of the stable aspects of the system.
However, in regard to some of the architecture choices, continuous debate will not cause any change and may reduce the possible usage of the resulting API if they are forced through. The sole use of interfaces is one of those requirements for me. Sorry if that is offensive, but we have already made hard and fast decisions about some architectural principles during the last 12 months, which required a lot of discussion already, and which Reto was privy to but chose not to say anything about some of these issues until now. To be a success across the widely varying communities that have historically been very disjoint, we have to be consistent and make the API as applicable as possible to all of the implementations, in addition to using the published RDF-1.1 W3C Recommendation as our main reference for technical aspects and the scope of the system. I.e., we aren't planning on being fair to any particular implementation, we would prefer to reduce the number of technical obstacles for all theoretical implementations. In this case there is a clear technical obstacle which is added if we change any of our interfaces to classes, and comparatively there is no actual difference if we stay with interfaces, hence why we already decided this issue in our initial phases and nothing except full consensus will change that. Similarly with the other issue where an implementor has been lobbying for their particular preference to be adopted, with regard to casing, there is no current or near future technical obstacle to upper-cased acronyms. We are only providing interfaces to override to give other implementations a common reference for reusing their objects, not class names that they would need to reuse internally. In addition, we have a very limited scope intentionally in the hope of getting any of the major implementations to use Commons RDF at all, so we do not envisage any multi-acronym interface names even in the long term. Hence, given that the status quo holds significant sway over any alternative except full consensus, continued implementation specific lobbying in the hope of scraping across the line to majority consensus may be starting to turn some of the contributors and implementers away. Cheers, Peter On 31 March 2015 at 19:20, Benedikt Ritter <[email protected]> wrote: > 2015-03-30 23:40 GMT+02:00 Peter Ansell <[email protected]>: > >> The use of interfaces is a deliberate step to improve the usefulness >> of the API by not mandating any particular implementation. We are not >> going to change that. >> > > ... unless the community builds consensus about such a change. > > >> >> I don't understand what makes a simple String a bad choice for >> representing language tags. There are no other attributes that could >> be attached to the string, per the BCP47 design to have all of the >> information required in a simple string. In addition that BCP47 string >> literal is all that is referred to in RDF-1.1, which is our core >> reference, not the JVM or other libraries design choices. Ie, the >> RDF-1.1 specs do not disect the language tag, so we see no need to do >> so here. The equality rules (lower case comparison with any casing for >> the tag literal itself) are all defined at the total level, so in that >> case it also doesn't make sense to decompile the string. >> >> On 31 March 2015 at 00:21, Reto Gmür <[email protected]> wrote: >> > Hi Andy, >> > >> >>> >> >>> and you have evolved to something for Clerezza that is not interface >> >>> based, which, as already commented (no response from you BTW) is a >> >>> roadblock for some. There was a point about scalability as well. >> > >> > I was waiting for jira, I will create an issue to address this. I think >> > IRIs and and language should be glasses. The current code uses an >> interface >> > IRI (a different from URL and URI in the java core library for which I >> fail >> > to understand the justifying use cases) and a String to express the >> > language tag (poor OO and wrong identify criterion, as the casing of the >> > language tag makes is irrelevant). >> > >> > As for scalability I don't know what you are referring to. >> > >> > I will create issues and answer your other points when I'm back on a >> better >> > connection. >> > >> > Cheers, >> > Reto >> > > > > -- > http://people.apache.org/~britter/ > http://www.systemoutprintln.de/ > http://twitter.com/BenediktRitter > http://github.com/britter
