[ 
https://issues.apache.org/jira/browse/ANY23-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13287145#comment-13287145
 ] 

Peter Ansell commented on ANY23-83:
-----------------------------------

I rebased my git repository onto a copy of the current trunk to check how many 
patches I still had in this area and noticed that RDFSchemaUtils still 
hardcodes the supported formats. I may not be seeing the significance of 
VocabularyFormat currently, but I assume that it could be generalised to any 
RDFFormat.

Is it related to the ability to type in a human readable alias for the format 
in VocabPrinter? If so, have you tried using RDFFormat.valueOf(String) in the 
converter inside VocabPrinter which matches against registered formats using:

    format.getName().equalsIgnoreCase(formatName)

These names may not exactly match the historical names for each format that 
were previously used, but they are extensible at runtime so it makes 
RDFSchemaUtils easier to maintain. This may also help with ANY23-3 as N3 would 
be available, although it would just be the Turtle subset in practice as we 
only hold RDF triples in memory.
                
> 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
>            Assignee: Michele Mostarda
>             Fix For: 0.7.0
>
>         Attachments: any23-rdfwritertriplehandler.diff, 
> any23-rio-naive-mime-detector.diff
>
>
> 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

        

Reply via email to