Re: Issue with Jena/sparql.org and XML Literals?

FWIW, I ran into this issue with my implementation as well... 

I have done a DOM based implementation in Perl.  It works well, and 
currently passes all tests except 100-103.  Once Manu's most recent 
changes are integrated I am going
to make a small change to my implementation and then it should pass all 
the tests.

My plan is to bundle up my impl as a Perl CPAN package that will (only) 
generate ntriples. It is "pure perl" in that it requires no C language 
extensions.  As such, it is portable to all platforms that support 
Perl.  Could be useful for some.

Ivan Herman wrote:
>
>
> Manu Sporny wrote:
>> Seaborne, Andy wrote:
>>> It is possible to get non-canonicalized XML literals into the data 
>>> by using datatype XMLLiteral even in RDF/XML.
>>
>> So this means that @datatype and @parseType don't do the same thing when
>> dealing with XML Literal data.
>>
>> The string in the element containing @datatype isn't modified at all.
>>
>> The string in the element containing @parseType IS modified via XML
>> Exclusive Canonicalization.
>>
>
> And as I commented before, I wonder whether this is not a bug in the 
> RDF/XML spec. However, this group should not spend too much time on an 
> issue that is not for this group to solve...
>
>> Ivan, the easiest thing to do at this point is for you to NOT change
>> your implementation and I'll just write the SPARQL to match what your
>> implementation generates.
>>
>
> Yes, that is fine.
>
>> Although, in light of this new discovery, it makes the learning curve
>> even steeper for XML Literals.
>>
>
> :-(
>
> Ivan
>
>> -- manu
>>
>

-- 
Shane P. McCarron                          Phone: +1 763 786-8160 x120
Managing Director                            Fax: +1 763 786-8180
ApTest Minnesota                            Inet: shane@aptest.com

Received on Wednesday, 11 June 2008 15:11:46 UTC