W3C home > Mailing lists > Public > www-tag@w3.org > February 2011

Re: Javascript fragid semantics

From: Robin Berjon <robin@berjon.com>
Date: Wed, 9 Feb 2011 13:29:51 +0100
Cc: nathan@webr3.org, Jonathan Rees <jar@creativecommons.org>, www-tag@w3.org, Ben Adida <ben@adida.net>
Message-Id: <8826B924-CCDB-46DF-817E-22494511240D@berjon.com>
To: Tim Berners-Lee <timbl@w3.org>
Hi all,

I stumble onto this message only now.

On Jan 30, 2011, at 17:40 , Tim Berners-Lee wrote:
> On 2010-12 -02, at 12:50, Nathan wrote:
>> core.js:
>> FastGraph = function FastGraph(a) {
>> ...
>> 
>> and #FastGraph being used to refer to that class as it's defined in the global scope of the js file.
> 
> Yes. exactly.
> So now, we can use the full URI, 
> 	http://example.com/code/libs/core.js#FastGraph
> 
> How would we use it?
> 
> Yes, we could say 
> 
> 	fg = webImport('http://example.com/code/libs/core.js#FastGraph')
> 
> where webImport would
> 	- return the function immediately if it is cached already
> 	- check whether the path involved matched your trust criteria
> 	- get the file http://example.com/code/libs/core.js
> 	- load it into javascript
> 	- check maybe for other modules which it needs
> 	- find the function FastGraph within it
> 	- return that

You may wish to look at the CommonJS require() method, which essentially does that and takes a simple (simpler than the above) approach. Basically, every JS file defines a module that has a variable called "exports" in its scope. That exports variable is what's returned when the module is required.

  var dahut = require("libs/crypto/dahut");

You get that module's exports returned. So to reformulate the above example, you'd have

  exports.FastGraph = function () { //...

based on which you could do:

  var fg = require("graphing").FastGraph;

Note how the native field accessor replaces the fragid. I'm unsure as to how implementations cache the loading, though it's an interesting question since one could generate different exports over multiple invocations.

Applying this to a web context is interesting because you normally really don't want to block on each require to wait for the resource to be loaded (which the example code you show would necessitate). There are discussions around this in the CommonJS project:

  http://wiki.commonjs.org/wiki/Modules/AsynchronousDefinition
  http://wiki.commonjs.org/wiki/Modules/Transport

An implementation of this is RequireJS: http://requirejs.org/. To make a long story short it's essentially the same principle but with callbacks and some hooks to make exports work in browsers. A project inside W3C that uses this extensively is (shameless plug) ReSpec2: http://dvcs.w3.org/hg/respec2/.

> and later ask you whether you would like to install the package
> and its dependencies for faster use and offline use.

There's no installation part in these techs, but you always have caching (and AppCache).

> of course, my choice for the metadata of dependencies would be RDF.

To which I'm really tempted to say: *bzzzzt*. I really don't think that information which when removed causes the representation to become unusable or meaningless can be considered metadata. In fact that's pretty much the definition of information: you can't remove it without losing meaning. Removing dependencies has a nasty tendency to make code unusable (and, in effect, meaningless). Dependencies should be part of the content.

Which isn't to say that you can't extract that information or that RDF isn't a good way of representing such graphs. You can and it is. But there shouldn't be a way of specifying dependencies external to the content or it's authoritative metadata all over again.

-- 
Robin Berjon - http://berjon.com/
Received on Wednesday, 9 February 2011 12:30:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:30 GMT