[
https://issues.apache.org/jira/browse/ANY23-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13272219#comment-13272219
]
Lewis John McGibbney commented on ANY23-83:
-------------------------------------------
Hi Peter,
{bq} I am not familiar enough with the rest of the codebase to know why the
shortlist of supported parsers is in place [bq}
Although I have tried to get to grips with as much of the codebase as I have a
use-case for, I am sorry as I cannot provide insight into the original design
considerations which you refer to... maybe one of the other guys could chime in
here and clear the picture for us?
I must admit though, I am in agreement with your overall analysis and think
that the more extensible we can make the Any23 libraries the better. There was
some discussion however over in ANY23-19 where the vision was to have an
abstraction layer between Any23 and the underlying RDF API's. In my opinion,
this would provide far greater potential for us to make Any23 a more flexible
library... wdyt?
> Remove hardcoded formats throughout Any23 to make it useful as a library
> ------------------------------------------------------------------------
>
> Key: ANY23-83
> URL: https://issues.apache.org/jira/browse/ANY23-83
> Project: Apache Any23
> Issue Type: Improvement
> Components: core
> Affects Versions: 0.7.0
> Reporter: Peter Ansell
>
> Many classes inside of Any23 seem to hardcode restrictions on the supported
> formats, making it difficult to utilise Any23 as an extensible library.
> One example of this are RDFSchemaUtils that artificially restricts itself to
> three formats using an enum mapping, where it could easily accept any
> RDFHandler, even if it were not an RDFWriter.
> Another example is RDFUtils where the list of RDFParser's is hardcoded in,
> and enforced using an enum.
> What was the reasoning for creating artificial format classes and manually
> mapping them to writers/parsers instead of using either allowing any
> RDFHandler in the first case, or allowing any accessible RDFParser in the
> second case, using Rio.getParser() to avoid hardcoding anything.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
