W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > July 2011

Re: API behavior when content hasn't loaded fully yet

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 11 Jul 2011 17:49:54 +0200
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: public-rdfa-wg@w3.org
Message-ID: <1310399394.2361.38.camel@shuttle>
On Sun, 2011-07-10 at 13:51 -0400, Manu Sporny wrote:
> On 06/13/2011 08:02 AM, Henri Sivonen wrote:
> > It seems to me that http://www.w3.org/TR/2010/WD-rdfa-api-20100608/
> > isn't explicit about how the API is supposed to work when the main
> > document itself hasn't loaded fully and when external RDFa Profiles
> > haven't been loaded yet.
> 
> It isn't. We need to work on that. Thanks for the bug report, Henri.
> Your request was logged weeks ago, but I forgot to ping you when we did it:
> 
> http://www.w3.org/2010/02/rdfa/track/issues/96
> 
> > Please define how the API should behave when the relevant resources
> > haven't been fully loaded and how a JavaScript application can find out
> > that all the relevant resources have been loaded.
> 
> Do you have any preferences on how we should go about doing this? Are
> there mechanisms that you feel work well today that should be mirrored
> in the RDFa API specification?

My first preference would be to design the language in such a way that
there'd be no need for prefix mappings at all--neither internal nor
external.

But if there are external resources, the mechanisms that are known to
work are 
 1) Firing an event when external resources are available.
 2) Registering a callback that gets called asynchronously when all the
required data is available (if all the required data is already
available when registering the callback, it would be a good idea to make
a trip through the event loop anyway to make sure that the callback
always gets called asynchronously so that authors don't accidentally
rely on synchronous behavior).

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Monday, 11 July 2011 15:50:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:17 GMT