[
https://issues.apache.org/jira/browse/JENA-862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14296681#comment-14296681
]
Andy Seaborne commented on JENA-862:
------------------------------------
NodeFactory(Extra) is a low level mainl yinternal class in the SPI (S=System).
At this level, Jena can work with relative URIs. It is not the responsibility
of this layer to resolve URIs - in fact, resolution is the responsibility fo
data coming in, typically parsers.
Your code, that has the base URI accessible, can do that resolution (test to
see if the result of parserNode is a relative or absolute URI using Jena's IRI
and IRIResolver). Note that the policy behind IRIResolver is itself
configurable so URI testing is not fixed. If you wish to contribute a addition
for passing in a baseURI , please do so but the current code is not a bug.
Your comment about namespaces/qnames isn't quite right - they only apply to
absolute URIs. In Turtle/TriG SPARQL, the prefix mechanism would because it's
pure concatenation but then the URI is resolved immediately in a parser.
{{getNamespace}}/{{getLocalName}} exist from a time when there was only RDF/XML
and they support that syntax only. Jena has always provided stability so
removing them has not happened - they back up application visible RDF API
operations.
The result is correct in one sense and not in another.
They are meaningless because the operations are being applied to a relative
URI. Perfect checking of URIs at this point is not practical (it's a low level
SPI) as it is way too expensive. IRI checking, as Jena does it, is
comprehensive.
They results are the best the code can do - an qname XML must start with a
letter; it chooses the longest local name. Namespace can't be empty.
It is even possible getLocalName will return "" which is illegal in a qname.
I hope that explains why things are the way they are. If your code wants to
IRI resolution, this is not the place that does it. Either do it before or
after calling parseNode, or make a contribution to Jena to add an operation for
discussion.
> NodeFactoryExtra.parseNode() gives wrong result for "<someLocalName>"
> ---------------------------------------------------------------------
>
> Key: JENA-862
> URL: https://issues.apache.org/jira/browse/JENA-862
> Project: Apache Jena
> Issue Type: Bug
> Components: Jena
> Affects Versions: Jena 2.12.1
> Reporter: Hendy Irawan
> Priority: Trivial
>
> For example:
> {code}
> NodeFactoryExtra.parseNode('<hasPopulationDensity>')
> {code}
> (prefixMap has no effect, I even tried setting a "default" namespace by
> adding prefixMap ''='http://yago-knowledge.org/resource/' but has no effect)
> It gives a {{Node_URI}} with:
> * toString() = hasPopulationDensity
> * nameSpace=h
> * localName=asPopulationDensity
> I'd expect {{nameSpace=null}} and {{localName=hasPopulationDensity}} at the
> minimum.
> Or if possible, support a default namespace in prefixMap so when a "" prefix
> is configured I can get:
> * toString() = http://yago-knowledge.org/resource/hasPopulationDensity
> * nameSpace=http://yago-knowledge.org/resource/
> * localName=hasPopulationDensity
> Or perhaps I'm doing this wrong?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
