RE: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.

Hello Marcos,

> -----Original Message-----
> From: Marcos Caceres [mailto:marcosscaceres@gmail.com]
> Sent: 04 December 2008 22:21
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: www-tag@w3.org; public-webapps;
> public-pkg-uri-scheme-request@w3.org
> Subject: Re: Sketch of an idea to address widget/package
> addressing with fragID syntax and media-type defn.
>
> Hi Stuart,
>
> On Thu, Dec 4, 2008 at 8:02 PM, Williams, Stuart (HP Labs, Bristol)
> <skw@hp.com> wrote:
> > Marcos,

<snip/>

> > Also, with some irony, I think that I'm beginning to get a
> > better understanding of your problem, the key for me being
> > your assertion in an earlier messages:
> >
> >        "I think we have different goals in respect to [3], and that might be
> >        causing me confusion. For instance, Widgets do not have a need to
> >        remotely access and reference items within a web accessible package.
> >        Conversely, Web apps just needs to access files within a locally
> >        stored package."
> >
> > Your problem is centered around how to generate absolute
> > URI from package relative URI driven primarily by a need for
> > API compatibility rather than a need to be able to make
> > global sharable references.
> >
>
> yes :) I know, that's a bit short sighted.
>
> > I don't know whether "...do not need to..." means simply
> >"...don't..." or even more strongly "...will never have
> > to...". If the possibility exists then I think that your
> > requirements need to take that into account. OTOH if it is
> > *never* going to happen... I'll have to scratch my head a bit
> > more to think about how you'd come up with a base URI and
> > what the risks were of essentially a locally scoped
> > identifier escaping into the wild by accident.
> >
>
> I think we are both starting to see each others' position more
> clearly, which is great. So, to be clear: at this moment in time, in
> what we are specifying for Widgets 1.0, our position is that that
> widgets "don't" need to remotely access or reference items within a
> Web accessible package. However, this does not means we would not want
> to do that in the future. So if that functionality is specified as
> part of this effort, then that is a good thing and widgets may use it.

At the TAG F2F last week we began to start discussing responding to the direct request that you made to us for feedback:

http://lists.w3.org/Archives/Public/www-tag/2008Nov/0114.html "...I again ask the TAG for direct feedback on the following URI-related requirements, which I have modified post the F2F meeting."

You go on to quote requirements R6 and R36.

We persued R6 and chased down some discussion of configuration documents and thence found:
http://dev.w3.org/2006/waf/widgets/#step-1 ins the chapter of Widget spec titled:

        "8. Steps for Processing a Widget Resource"

...in particular step (#1) titled:

        "Step 1 - Acquire a Potential Zip Archive from the Network, or from Local Storage or Other Media"

which suggests that networked based acquisition of widget resources is very much part of your design. Given what you have said that has left the TAG and I a little confused about your requirements for networked references.

It strikes me that *if*, as appears to the case, there is a potential need to be able to reference, obtain/install widget packages across the network, then you should factor that into your design early. I see 3 broad requirements:

1) relative addressing withing the package -
   basically uri: scheme-less with absolute (from package root) or relative paths.
   question arises of how to turn internal relative references into absolute URI.

2) referencing into a package from 'outside' -
   which requires some means to refer to the package as a whole plus
   an approach to refering inside the package.

3) [Possibly] referencing between instantiated widgets -
   (ie referencing run-time objects rather than the (shared?) package(s) from which they are instantiated.)

Can you help us more specifically with set of scenarios that more clearly illustrate your requirements for networked package/widget referencing and access?

BTW: When it comes to some page/web-app instantiating a widget... how does the publisher/developer make reference to the widget to be instantiated and/or the package from which it is to be instantiated (if those are regarded as separate things)?

<snip topic="URI leakage"/>

>
> Kind regards,
> Marcos
> --
> Marcos Caceres
> http://datadriven.com.au


Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Monday, 15 December 2008 15:20:08 UTC