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

Re: "GRDDL Agents" section, normative security text for review (# issue-conformance-labels)

From: Harry Halpin <hhalpin@ibiblio.org>
Date: Sat, 17 Feb 2007 17:35:30 -0500
Message-ID: <45D78332.9020905@ibiblio.org>
To: Dan Connolly <connolly@w3.org>
Cc: Murray Maloney <murray@muzmo.com>, GRDDL Working Group <public-grddl-wg@w3.org>, Jeremy Carroll <jjc@hplb.hpl.hp.com>

As regards the possibility of recursion in GRDDL, I noticed this earlier
when making the grddlonrdf testcase, so I wrote a quick test-case. Try
to see what happens when you GRDDL this URI:


Chime's GRDDL.py does appear to go into an endless loop - on my machine,
I get a "  File "/usr/lib/python2.4/random.py", line 188, in
randrange    if width >= maxwidth:
RuntimeError: maximum recursion depth exceeded in cmp"


We could underspecify this or add my test to the test-suite and add some

The way to fix this problem I think is to specify at some point that a
GRDDL parser is not "greedy." I think about this functionally - a GRDDL 
is a function f from S (where S contains a triple licensing a GRDDL
transformation)  to G. So, f(S)=G. However, can we compose f multiple
times? This should not be allowed, since for the base case  f(f(S)),
since for any given f one cannot guarantee that f will result in a G'
such that f(G)= G' where S=G'. If S=G', one has infinite recursion. By
induction, this is true for all cases. This is a functional, as opposed
to declarative way, of thinking about GRDDL. A call to a GRDDL parser is
a single function application.

 IMHO, if you explicitly create an infinite loop it's your fault, but if
it's implicitly allowed in the Spec to be done in a single call of a
GRDDL parser, it's our fault.

So, to phrase this point declaratively, maybe just add this to the spec:


"If a GRDDL result contains a transformation as given by 1-4, do not
apply the transformation in the result document."

Or, if one wanted to by very formal about it, one could say:

"If there exists for G an additional transformation property TP',  then
TP' is not applied to G. "

There's quite a few ways one could say this declaratively, but that's
the simplest I think.


Dan Connolly wrote:
> On Sat, 2007-02-17 at 14:27 -0500, Murray Maloney wrote:
>> Looks quite good. The protocol trace is a nice touch.
> Yes, I had fun with that...
>> I have a quibble with step 2....
>> [...] a GRDDL Agent should:
>> 1. Find each transformation associated with N, i.e.
>> 	[...]
>> 2 Apply each transformation to obtain a GRDDL result.
>> 3 Merge those GRDDL results.
>> I agree that an agent should be aware of each transformation that is 
>> associated with N.
>> I also agree that results should be merged.
>> However, I think that a GRDDL-aware agent should have some discretion
>> with respect to which transformation(s) are applied. Perhaps that is the
>> reason that "should" was used instead of "must".  In a given situation,
>> only one or a specific set of transformations may be applicable -- at the
>> discretion of the client on whose behalf the agent is performing.
> Yes, it should have some discretion. I meant for "local policy
> an configuration" to convey that sense of discretion...
> "Given a URI I of an information resource IR, and an XPath node N for a
> representation of IR, subject to security considerations below and local
> policy and configuration, a GRDDL Agent should:"
> Is that perhaps clear enough on second look?
>> Also -- I suppose that I should have thought to ask this question a long 
>> time ago
>> -- but what happens if the merged GRDDL result contains a grddl:transformation?
>> Is that result final, or are we expected to recurse until we have exhausted 
>> transformation
>> links?
> No, the spec doesn't say to recurse in that situation. (At least:
> it isn't meant to, and I don't _think_ it says to.)
> I suppose you could build an agent whose policy was to treat GRDDL
> results as not just data to be passed on but true facts to be
> acted upon. But that would go beyond the spec, at least as
> currently written.
>> Regards,
>> Murray
>> P.S. I noticed that my name is mentioned under acknowledgements in connection
>> with a W3C meeting held in France in 2004. I did attend a meeting, but it 
>> was in March 2006.
> Oops; I got the 2004 and 2006 meetings blurred together in my head.
> Fixed in Revision 1.222  2007/02/17 21:58:04
> http://www.w3.org/2004/01/rdxh/spec#changes
>> And thanks for the mention.
> Welcome.


Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426
Received on Saturday, 17 February 2007 22:35:42 UTC

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