[
https://issues.apache.org/jira/browse/ANY23-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13271977#comment-13271977
]
Peter Ansell commented on ANY23-83:
-----------------------------------
I was hoping that Any23 would be extensible to more than the current list of
supported parsers. I understand that when Any23 was originally developed that
it would have needed to restrict itself to a small set of supported parsers. I
am not familiar enough with the rest of the codebase to know why the shortlist
of supported parsers is in place, but it would be good if it could be made
generic in the future.
In terms of a generic factory type implementation, one could use the SPI based
Rio.getParser(RDFFormat) or any of the other static methods in the Rio class.
RDFFormat is not a fixed enum, so it can be extended, and the parsers are
instantiated using RDFParserFactory implementations instead of directly created
[1]. The mime-types are described inside of RDFFormat as a list, with preferred
and alternate mime types, and the RDFParserFactory implementations that are
found using SPI are each tested to see if the RDFFormat that they support fits
with a given mime-type before the parser is instantiated.
In terms of RDFSchemaUtils, it is not clear why the list is restricted the way
it is, as it would be very useful to be able to patch any RDFHandler in, and
would not take much coding to make the change as far as I can tell.
[1] http://www.openrdf.org/doc/sesame2/api/org/openrdf/rio/RDFParserFactory.html
> 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
