From: Rob V. <rv...@do...> - 2012-09-24 21:40:07
|
Hi Uldis Yes that was indeed still a bug, the parser was incorrectly parsing the Base URI into a library wide utility function which resolves QNames. That function falls back to using the Base URI if present when the QName references the default namespace and no default namespace is defined. That behavior is correct and used by some parsers but shouldn't have been used for RDF/XML The code is now fixed so documents like the one you provided will result in an error. Thanks for the report, Rob On 9/24/12 12:44 PM, "Uldis Bojars" <cap...@gm...> wrote: >Hi Rob, > >Thanks for looking into this. > >> The RDF/XML specification has the following to say on relative URI >> resolution: > >It might be more of a problem with what is allowed in the RDF Property >element name than with relative URIs (which, indeed, are fine as the >program is allowed to determine the base URI itself). > >At least a modified example with xml:base added still produces same >W3C RDF validator warnings: > ><rdf:RDF xmlns:dc="http://purl.org/dc/elements/1.1" >xml:base="http://captsolo.net/" > xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> > <rdf:Description rdf:about="http://localhost:8081/data/obj/1000"> > <error>no info how to convert this element: creator</error> > </rdf:Description> > </rdf:RDF> > >Error: {W104} Unqualified property elements are not allowed. Treated >as a relative URI.[Line = 4, Column = 13] >Error: {W136} Relative URIs are not permitted in RDF <error>[Line = 4, >Column = 13] > >> When invoking the parser directly it does not assign a Base URI to the >> Graph hence URI resolution fails and you get a parsing error. > >As noted above it might be something else (at least for W3C validator) >but as long as DotNetRDF is able to notify about issues like this (it >is, provided the parser method is used) I have nothing to complain >about. :) > >> So this behavior is a little inconsistent and confusing but it is >>somewhat >> by design, the LoadFromFile() and FileLoader.Load() methods are designed >> to be user friendly abstractions which remove some of the complexity of >> selecting a parser and invoking it while also protecting users from some >> common errors e.g. missing Base URI by setting up the parser invocation >> appropriately. > >Would it make sense to document this difference in behavior? (E.g., >add a notice / warning to user-friendly methods saying the warnings >will be hidden) > >It would help in cases like mine when looking for a parser that would >warn of malformed RDF and other errors (to use as an RDF validator). >In this case a user-friendly parser is not helpful at all and it is >good to know one has to look at the parser method instead. > >> We could change the behavior to make it consistent (invoking a parser >> directly on a file would set the Base URI for the Graph) but then we are >> hiding errors from advanced users. > >Hiding errors from advanced users does not sound good :) > >Also, setting the Base URI might not get rid of the warning (maybe it >does, I did not try the modified version on DotNetRDF yet). > >> With regards to warnings I don't have an example but it uses the >>standard >> .Net event pattern, Warning is an event defined by all IRdfReader >> implementations and you add an event handler to it like any other .Net >> event >> >> parser.Warning += new RdfReaderWarning(handlerMethod); > >I'll have to explore it. I have a reasonably good knowledge of RDF but >a very limited knowledge of .Net or C#. > >Thanks, >Uldis |