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

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