Re: [RDF] Include RDFParserBuilder in 0.3.0?
On 15 September 2016 at 12:06, Stian Soiland-Reyes wrote:
> [[ Cross-posting - let's try to reply to dev@commons. ]]
> b) Move RDFParserBuilder to package org.apache.commonsrdf.experimental
> or similar (allowing us to fully change it for the next version)
> c) Same as b) - but also move RDFParserBuilder implementations to e.g.
> org.apache.commonsrdf.jena.experimental
> e) Remove RDFParserBuilder.rdfTermFactory()
These are my proposed changes - I'll go ahead on these unless I hear
otherwise :)
Commons folks - is the use of a ".experimental" sub-package (and
appropriate Javadoc) OK?
Suggested javadoc:
package org.commons.rdf.api.experimental;
/**
* ...
*
* NOTE: This interface/class is currently marked as
experimental,
* meaning that it might change or be removed in the next minor version.
*/
public interface RDFParserBuilder {
// ...
}
I'm not proposing we go all Guava style with lots of experimental
annotations (and the well known incompatibility issues following),
just for this 0.3.0-incubating version - so we can decide later on the
final form of that interface for the following (hopefully 1.0.0)
version under Commons proper.
--
Stian Soiland-Reyes
http://orcid.org/-0001-9842-9718
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[RDF] Include RDFParserBuilder in 0.3.0?
[[ Cross-posting - let's try to reply to dev@commons. ]] I guess this is mainly of interest to Commons RDF folks - but there's some question baked in here on what to do with an experimental interface. Note that the next incubator release of Commons RDF is "0.3.0" - so we could still 'break' for a first Commons-release 1.0.0 (although it might still not be too nice to downstream users) If we agree to add the jena/rdf4j/jsonld integrations to the Commons RDF 0.3.0 release (I hope we do!), what should we do with the new interface RDFParserBuilder ? http://stain.github.io/incubator-commonsrdf/integration/org/apache/commons/rdf/api/RDFParserBuilder.html I think it is very useful for allowing parsing of RDF with the different backend libraries. Note that I have not yet made the corresponding RDFWriterBuilder as I would want it to mirror the same design. However this was a bit experimental API design which has changed a couple of times, so it's not really had much hammering yet. For instance I am not sure there is much point in setting rdfTermFactory() as it was difficult with each of the implementations to effectively use that factory. (it would require deep change of the parsers). It's also a bit up in the air if there's any point of the asynchronous "Future" return type of .parse() I like that it allows IO timeout & cancelling, but that could in theory lead to thread pool fill-up if incorrectly handled - all the parsers are effectively synchronous single-threaded. All the implementations use the base class AbstractRDFParserBuilder http://stain.github.io/incubator-commonsrdf/integration/org/apache/commons/rdf/simple/AbstractRDFParserBuilder.html (to handle the builder pattern and pre-flight checks) But this mean they get a dependency on the 'simple' module - which mean you would then always find two RDFTermFactory implementations on their classpath (ServiceLoader might pick the 'wrong' one). Is that OK? Should we: a) Delete RDFParserBuilder (and the implementations) for 0.3.0 b) Move RDFParserBuilder to package org.apache.commonsrdf.experimental or similar (allowing us to fully change it for the next version) c) Same as b) - but also move RDFParserBuilder implementations to e.g. org.apache.commonsrdf.jena.expeimental d) Move AbstractRDFParserBuilder to api module e) Remove RDFParserBuilder.rdfTermFactory() f) make RDFParserBuilder.parse() synchronous g) RDFParserBuilder is good as it is - release it in 0.3.0! Views welcome! -- Stian Soiland-Reyes http://orcid.org/-0001-9842-9718 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
