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

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:

http://www.ibiblio.org/hhalpin/homepage/notes/recursive.rdf

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"

Ouch.

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

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:

Under:
http://www.w3.org/2004/01/rdxh/spec#sec_agt

"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.


       -harry






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

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Saturday, 17 February 2007 22:35:42 UTC