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

On Feb 5, 2011, at 16:11 , Gregg Kellogg wrote:

> I was just chatting with Manu about this very issue the other day. I just had to fix a similar bug in my processor.

I actually had this issue in my running version a while ago, but I am looking at a dynamic caching version so I was looking at this again...

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

Yes, this is exactly what I did, too. But one has to be careful that this should also work when there is an autoreference of a profile, which is the case for the default profile. That is the case that I did not handle in my current version.

But... strictly speaking this may fail on the default profile in case that profile is not properly done. Indeed, if the default profile file refers to any prefix that is, well, defined by itself, then things goes wrong. Eg, if the default profile file makes use of the rdfs:comment predicate (which it may!) then there MUST be an extra @prefix attribute for the rdfs prefix, in spite of the fact that for _all_ other RDFa sources this is unnecessary...

Not nice.:-(

> 
> I agree that the spec should address this issue and suggest a similar workaround.

That is for sure!


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


Indeed. And the current spec states that the profile MUST be available in RDFa and MAY be in other serializations...

Ivan




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


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