Re: Built-in infinite recursion in our spec? (related to ISSUE-73 and ISSUE-78)

I was just chatting with Manu about this very issue the other day. I just had to fix a similar bug in my processor. If the processor accepts any result from @profile, this will include encodings with RDFa. Of course, @profile is not limited to RDFa either. The bug reporter had a page that had RDFa on it, as well as hCard. The hCard profile is, in fact, recursive!

My solution is to add an entry to my PG repository prior to parsing the referenced profile. I then check this and return previously parsed results before processing. This aborts the recursive call.

I agree that the spec should address this issue and suggest a similar workaround. It's also probably a good idea to make the GET request with an ACCEPT header that places HTML at a lower priority than N3, Turtle or RDF/XML (only RDF/XML has official mime type at this point). However, this doesn't eliminate the issue, and such a procedure  is required.

Gregg Kellogg

Sent from my iPad

On Feb 5, 2011, at 2:37 AM, "Ivan Herman" <ivan@w3.org> wrote:

> This morning when I was still half-asleep (I am serious!) it hit me that we may have an issue.
> 
> We have been discussing default profiles as being profiles like all the others, the only difference being that one is not required to "declare" it via @profile in RDFa. So far so good. But we also say that any profile (ie, the default profile, too) must be made available via RDFa. Which means that the default profile has an (implicit) declaration to itself as a profile. Ouch, we have an infinite recursion per specification... And a very subtle rope we give implementations to hang themselves.
> 
> Note that the issue may occur with any profile. If a profile is in RDFa, it may refer to other profiles, ie, an implementations may have to be careful not to get into an infinite recursion. And it is not always as simple as for default profiles; after all, profile A may refer to profile B that may refer to profile C that may refer to... A. Oops...
> 
> So something must be said and implementations must be careful. At the minimum, we may have to say something like an RDFa profile file cannot refer to itself (ie, that implementations should ignore that) although we may get into subtle issues that are not that simple to handle. For example: say, the profile URI is http://www.example.org/profile. I do a HTTP GET and I get back the file (after content negotiation): http://www.example.org/profile.html. Technically, that is a different URI, so I will have to keep track of all these variations. Messy, messy...
> 
> There is another way out (that I do not like, but I just put it out there): that a profile file has to be encoded in... something else. Say, Turtle. That would take care of recursions (even if the RDF group does take up some profile mechanism, I would expect that Turtle, ie, the media type text/turtle, will not change). But I do not like it: if the prefix definitions are in RDF, it sounds unnatural to disallow a specific serialization format.
> 
> Another approach. Yes, I was one of those who advocated using RDF to encode profiles. So I might be the one who says: maybe that was wrong, and we should _not_ use RDF to encode them? That would certainly take the problem away. An obvious candidate would be JSON with something as simple as
> 
> {
>  "prefix" : { "prefix1" : "URI_p1", "prefix2" : "URI_p2", ... },
>  "term"   : { "term1" : "URI_t1", "term2" : "URI_t2", ... }
>  "vocabulary" : "URI_voc"
> }
> 
> But then we get into the disagreeable situation whereby the term/index definitions become separated from its documentation, which is one of the main advantages of using RDFa...
> 
> Sigh. Maybe somebody on the group has an obvious and easy solution...
> 
> Ivan
> 
> 
> 
> 
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
> 
> 
> 
> 
>

Received on Saturday, 5 February 2011 15:11:55 UTC