W3C home > Mailing lists > Public > www-tag@w3.org > December 2010

Re: Javascriptfragid semantics

From: Nathan <nathan@webr3.org>
Date: Thu, 02 Dec 2010 17:50:43 +0000
Message-ID: <4CF7DC73.3050407@webr3.org>
To: Tim Berners-Lee <timbl@w3.org>
CC: Jonathan Rees <jar@creativecommons.org>, www-tag@w3.org, Ben Adida <ben@adida.net>
Tim Berners-Lee wrote:
> On 2010-11 -29, at 19:05, Nathan wrote:
>> Tim Berners-Lee wrote:
>>> Well, not really.
>>> A general way of saying it is that the fragid is a document-global identifier in whatever language.   You invent a new language, and it get s new global identifiers
>>> So in a javascript module, for example,  I would expect
>>> foo.js#bar to be the  global variable bar in the file foo.
>> ahh insightful, I'd never seen it quite like that, so jumping a few hops one might conceivably specify a js require function and do something like:
>>  FastGraph = require('http://openjs.net/api/core.js#FastGraph);
> Yes, absolutely. With an RDF mesh of dependencies, that would
> be a nice packaging system.

Sorry Tim, it usually takes me somewhere between days and months to 
fully grok what you're saying - do you mean dependencies + class / 
method structure described in RDF with code included ala

Previously I'd just been thinking

   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.

> using core as 'http://openjs.net/api/core.js#' {
> 	var fg = new core::FastGraph();
> 	...
> }
> It was interesting to chat with Brendan Eick about the ecmascript and e4X (ecmascript for xml) history.
> He mentioned e4x is actually implemented for example in Rhino, and uses :: for namespaces,
> but only in the context of XML, not RDF or js itself.
> http://en.wikipedia.org/wiki/ECMAScript_for_XML
> http://www.ecma-international.org/publications/files/ECMA-ST/Ecma-357.pdf

There may be a way to leverage `with` for this, unsure - also, IIRC 
actionscript 3 also supports ev4 and :: namespaces for XML.

>> Thus enabling a universal require for js and an open web scale set of classes that can be used anywhere - although perhaps I read too far in to it!
> No, I think it would be neat.
> See the red_import() for Python which
> http://redfoot.net/2002/12/03/redfoot-1.7.3/doc/helloworld.html
> alas 404
>>> It is really important to be able to ivent new languages,
>>> and so it hard to say how theyr global address space will work.
>>> In the case of HTML and RDFA, we have a mixture of languages
>>> so an localid  can either identify an HTML anchor or a RDF concept.
>>> I don't like the idea of things being both.
>> Afaict, at runtime the two localids can never conflict, one is used within the scope of the DOM and the other combined with a string to create an RDF URI Reference / IRI - so is the issue that at webscale, when you encounter something with a fragmentid and that derefs to an HTML+RDFa document, you don't know to what it refers (wondering if again that's covered by the context within which you're asking the question),
> What a URI refers to must NEVER be covered by the context in which you ask the question.
> That is important web architecture.

noted, I'll remember that and update my thinking accordingly - and take 
a look at HTML + RDFa again with @id="foo" and @about="#foo" on 
different elements.

Wondering if js and N3inHTML [1] side scripts this by using <script 
type="media/type"> which does/might/should override the frag semantics 
for that part of the content.(?)

[1] http://esw.w3.org/N3inHTML

>> so then is it to do with what statements one may make about the said uri -with-frag thus creating possible ambiguity there?
> Well, might you want to use RDF languages to talk about fragments of a hypertext document too?
> 	ele:Mg a ch:Element;   :warningNotice <warnings#mg>.
> where warnings#mg is an anchor within an HTML document.
> Or also you might want an RDF view of the DOM inside a script.

Will have to come back to that one at a later date, the snow over here 
in scotland has me running at half mental capacity ;)


Received on Thursday, 2 December 2010 17:51:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:36 UTC