W3C home > Mailing lists > Public > public-grddl-wg@w3.org > April 2007

3XX issue

From: Jeremy Carroll <jjc@hpl.hp.com>
Date: Mon, 16 Apr 2007 18:22:03 +0100
Message-ID: <4623B0BB.6030209@hpl.hp.com>
To: GRDDL Working Group <public-grddl-wg@w3.org>

So implementing the TCN support, I hit a problem with

which redirects to
the Alternates response header is misunderstood, except in the context 
of the updated base URL http://www.w3.org/1999/xhtml/

Thus I modified by software to update it's notion of the current base 
URL after a 3XX redirect (which as far as I can tell is the meaning of 

But, this makes some of the GRDDL conventions problematic after a redirect.

As an example consider the multiprofile test that my software used to 
pass, but now fails.

My guess is the reason for the failure is the redirect on:

The profile uses the glean-profile library function, which uses a same 
document reference rdf:about="" to make the subject for the 
grddl:profileTransformation triples.

Because of the change in the way I am handling redirects, this same 
document referenced is now being interpreted as about 
rather than being as about http://purl.org/NET/erdf/profile

I think this is pedantically correct, and was motivated by the case 
http://www.w3.org/1999/xhtml/ where the server returns relative URIs (in 
the Alternate header) which assumes that my software is making such an 
interpretation of the base URI

Now, this relates to the following text in the spec:

     * an information resource PDOC, identified by an IRI PNAME has a 
GRDDL result that includes a triple whose
           o subject is PDOC, whose
           o predicate is the property 
<http://www.w3.org/2003/g/data-view#profileTransformation>, and whose
           o object is TX,
     * and an information resource IR has an XML representation with 
root node NODE that has a metadata profile name PNAME,

then TX is a GRDDL transformation of NODE.

A possible reading, which my software is currently making, is that the 
redirect says that the information resource is identified by

and the metadata profile name is

and so the transform does not fire.

If this is the correct reading, then a fix would be to add an (HTML) 
base element to
declaring it to be

My software would still get this wrong, and it is possibly unclear which 
URI should be used as the base URI when parsing the RDF/XML output of 
the glean-profile transform.

Is this at all clear?
Or do I need to try and write this message all over again.


Hewlett-Packard Limited
registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England
Received on Monday, 16 April 2007 17:22:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:39:11 UTC