Re: more struggles with POWDER test matierals


I asked Dom to take a look at this yesterday. His suspicion is that 
Redland throws it out as the XSLT uses XSLT 2. I've been asking people 
with other RDF tool kits to see what theirs does. We're checking Jena, 
for instance, and I wrote to Cimezie to see if he can try his 
implementation too (incidentally, it's because the first XSLT uses XSLT 
2 that I created a simple Perl script that does the same job, it's 
documented on the validator page

I don't expect any implementation to take a POWDER file and run both 
XSLTs in sequence and produce a POWDER-S file as output without some 
sort of intervention. What we've done is to link the schemas to the 
XSLTs in what looks like a sensible way. AIUI, GRDDL doesn't require 
that XSLT be the technology used so it seems that to expect a completely 
automated service discovery and execution seems a tall order. Or have I 
misunderstood GRDDL?


Dan Connolly wrote:
> Dom, are you available to look into this today?
> On Tue, 2009-05-05 at 14:47 +0100, Phil Archer wrote:
>> Removing TAG list for now, will reply to that list in due course.
>> Adding Dan Bri 'cos he was asking similar questions.
>> Dan,
>> There's been an update to the doc since your original comment. I believe 
>> you'll find that all the documents cited in the manifest files are 
>> correctly addresses but we'll double check them.
>> When preparing to send the PR transition request last week I found, 
>> somewhat to my horror, that the schemas I had believed to be in place 
>> weren't - that has now been corrected, complete with GRDDL links i.e. 
>> this was done after your TAG meeting.
>> The XSLTs [1,2] have been tested extensively (most of the GRDDL tests in 
>> the Test Suite are actually the output of the XSLTs) so we have no 
>> worries there. However, testing whether this works in an off-the shelf 
>> GRDDL tool is a little harder.
>> The example you chose was [3]. Put that into the W3C GRDDL service [4] 
>> and you get this error:
>> Failed to parse stylesheet in 
>> '' at line 1, column 
>> -1 in
>> Now... that means that the service is locating the correct XSLT - good. 
>> And we know that the XSLT works 'cos we've tested it till the cows come 
>> home [5]. So it isn't clear to me that this is a POWDER problem.
>> If you have an alternative GRDDL app available, I'd be grateful if you'd 
>> run that and see what you get.
> I get the same error, and I don't see why.
> Dom, would you please take a look?
>>  If there is a problem then, of course, we 
>> want to fix it. NB: there's a LOT of complexity here:
>> The namespace resolves to
>> which is the file that includes 
>> the data-view:transformation link to 
>> But, the schema imports others, notably the POWDER-BASE schema 
>> which in turn includes a 
>> data-view transform link to the second XSLT 
>> ( since POWDER to 
>> POWDER-S is a two-stage process.
>> Any advice you can offer would be most welcome.
>> Thanks
>> Phil.
>> [1]
>> [2]
>> [3] 
>> [4]
>> [5]
>> Dan Connolly wrote:
>>> In our 23 apr meeting*, the TAG reviewed my comment about
>>> the testcases not working:
>>>   powder-test/grddl/powder002.xml is 404?
>>> and decided to endorse it. It's hard for us to review POWDER
>>> with the test materials in their present state.
>>> Is there some way of using the test materials in their present
>>> state that we're just not aware of? Or are they actually broken
>>> and in need of a fix?
>>> * minutes pending; draft in member space:
>>> p.s. tracker, this is re ACTION-262


Phil Archer

i-sieve technologies                |      W3C Mobile Web Initiative
Making Sense of the Buzz            |

Received on Friday, 8 May 2009 13:52:04 UTC