Re: [Uri-review] Re: The 'javascript' scheme

Martin Duerst wrote:
> At 19:11 06/11/09, Graham Klyne wrote:
> 
>> My unease with the javascript: case is that it's not so easy to identify an
>> identified resource.  How is one to interpret a javascript: URI if it appears in
>> a non-hyperlink type of context where other URIs can and do appear?
> 
> Hello Graham,
> 
> Sorry, but I somewhat don't get "a non-hyperlink type of context
> where other URIs can and do appear". Can you give examples?

Well:
 * as a namespace identifier in XML
 * as a profile identifier in BEEP
 * as a resource identifier in RDF
 * as an XML schema URI
 * as the object of an owl:imports statement in an OWL schema
 * as the object of a log:semantics statement in CWM

> One example I have come up would be an XML namespace URI.
> In that case, the namespace would just be identified literally
> (i.e. by character-for-character comparison with other URIs
> to check whether they are the same namespace or not). Same
> for URIs/IRIs used in an RDF context.
> 
> Did you have this in mind (which in my eyes looks a bit too trivial
> for asking the question above) or something else?

I'd agree those are trivial most of the time, but I think the apparent
triviality here-and-now may mask future difficulties with evolving use of URIs
within the Web architectural framework.  What about, say, use as an owl:import
in an OWL ontology, or in application like CWM as the object of a log:semantics
statement?  In both of these cases, there's a cross-over between
URI-as-identifer and URI-for-retrieval.

The purpose of my initial question wasn't to say categorically that javascript
as URI is bad, but to try and understand how a URI scheme like this plays to
wider issues of web architecture.  The Web community has put much effort into
trying to avoid a messy dichotomy between these cases of URI-as-identifier vs
URI-as-mechanism - and I feel it would be good if we can understand how new URI
schemes can fulfil the various roles to which they are called. [*]

#g
--


[*] As it happens, I think there *is* at least one way to square this circle
w.r.t. javascript: URIs, but it's a bit obscure and to explain it I'd fall back
a bit on some theory of programming languages, so I haven't tried to offer it
thus far.  I offer it now not as a real suggestion, but to try and suggest some
direction in which the unease I raise might be addressed.

Roughly, a program can be thought of as an expression.  This is easy to see in a
pure functional programming language like Haskell:  a program is just an
expression that denotes a value - that value would be a representation of some
resource.  Thus far, it's quite like a data: URI.

But some programs are context dependent, in that the expression depends on
values out there in the real world (i.e. they perform input), and their
evaluation may also update values in the real world (outputs, or side effects).
 All these programs can be expressed in a pure functional form, though in doing so:
 (a) programs that take input have to be regarded as functions with "the real
world" as an input;  HTTP URIs can behave like this too, so no problem. (In
Haskell, this means they are evaluated in what is called the "IO monad".)
 (b) programs that have side effects, or perform output, are treated as
functions that return a new value of the real world -- Haskell also handles this
though its "IO monad", but describing the actual visible effects outside a
single program aren't covered by this.

Putting aside javascript programs with side effects, we could then say that a
javascript URI identifies some resource (without actually saying what, which is
true to a lesser or greater extent of other URI schemes), a representation of
which is returned by the program regarded as a function applied to the
real-world context in which it is used.

Programs with visible side effects are, I think, more problematic.

A practical consequence of this approach would be, I think, is that, taking into
account [http://www.w3.org/TR/2004/REC-webarch-20041215/#safe-interaction]
(specifically:  "Principle: Safe retrieval - Agents do not incur obligations by
retrieving a representation."), some restrictions should be placed on the kinds
of Javascript that are acceptable in a javascript: URI -- specifically, not
allowing Javascript with side effects visible outside the browser or application
in which they may be used.  For example, a Javascript URI should not invoke any
functions that update publicly visible data file systems or perform HTTP PUT or
POST operations.  This requirement would go beyond normal security constraints
for browser-side Javascript, as a URI can be used in all manner of contexts
other than a browser.


-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Friday, 10 November 2006 11:46:01 UTC