RE: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
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)? I'm sorry, I'm not sure I understand your question. Could you rephrase it or give me an example. Ok... I'll try, though I have read very little of the widget spec material, just the bits around addressing. When some webapp developer is developing a webapp they will have to refer in some way to the wigets that they want to use in their application - particularly for the cases where they expect some network retrieval to go on. All I'm asking is *how* they make that reference? - Just a URI refering to (a copy of) the Widget package; - some location independent Widget (package?) name? - a two part name (naming the package and naming the widget within the package)? FWIW, we have removed all requirements for Widgets to be embeddable into Web documents. When you say removed all requirements that doesn't say that current specs don't provide any capabilities there - only that you don't require them to. So... whilst it may not be something that you currently require do the specs that you are working on address or partially address embedding of widgets in Web documents. Widgets, as currently being defined by the Widgets 1.0 Family of Specifications, are solely packaged standalone client-side applications that are authored using Web technologies. BR Stuart -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England -Original Message- From: Marcos Caceres [mailto:marcosscace...@gmail.com] Sent: 20 January 2009 08:47 To: Williams, Stuart (HP Labs, Bristol) Cc: www-...@w3.org; public-webapps; public-pkg-uri-scheme-requ...@w3.org Subject: Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn. Hi Stuart, Sorry for taking so long to reply... On 12/15/08 3:16 PM, Williams, Stuart (HP Labs, Bristol) s...@hp.com wrote: Hello Marcos, snip/ 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. In regards to network acquisition, the processing that occurs in Step 1 just refers to downloading zip files (not acquiring the resources from within a package that is somewhere on the network). 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. This is exactly the only problem WebApps-WG was trying to solve. This is the highest priority for the WebApps-wg wrt Widgets 1.0. 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. Until now, this was _not_ a problem that WebApps was trying to solve. However, you have convinced me that this will be useful in the future and I would like to pursue it for Widgets 2.0. 3) [Possibly] referencing between instantiated widgets - (ie referencing run-time objects rather than the (shared?) package(s) from which they are instantiated.) This is a low priority item for Widgets 1.0. It is unlikely that it will make it into the spec. However, it is something that we may pursue in Widgets 2.0. Can you help us more specifically with set of scenarios that more clearly illustrate your requirements for networked package/widget referencing and access? Like I said, our main priority is 1). Simply: 1. Get widget package from HTTP(S): e.g.,
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:marcosscace...@gmail.com] Sent: 04 December 2008 22:21 To: Williams, Stuart (HP Labs, Bristol) Cc: www-...@w3.org; public-webapps; public-pkg-uri-scheme-requ...@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) s...@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
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
On Fri, Dec 5, 2008 at 3:42 PM, Jonathan Rees [EMAIL PROTECTED] wrote: I hate to burst ignorantly into a discussion I know little about... but that's what I'm going to do. Forgive me. Regarding the creation of local URIs for use in APIs requiring URIs: I want to consider, just as a what-if meant for clarification of requirements, the use of the tag: URI scheme [1], which appears on first blush to be a good fit. Suppose that the desired suffix of the URI is to be zzz. The URI would look like tag:widgets-r-us.org,2008:8948372837/zzz i'm 99% certain this is in the minutes from the F2F, a WUA needs to be able to instantiate multiple discreet instances of a widget, and needs to be able to distinguish them. the instances need to be distinct. Whether distinct instances should be able to enumerate and connect is not currently decided but for future improvement the scheme shouldn't prohibit this.
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
On Dec 6, 2008, at 9:58 AM, timeless wrote: On Fri, Dec 5, 2008 at 3:42 PM, Jonathan Rees [EMAIL PROTECTED] wrote: I hate to burst ignorantly into a discussion I know little about... but that's what I'm going to do. Forgive me. Regarding the creation of local URIs for use in APIs requiring URIs: I want to consider, just as a what-if meant for clarification of requirements, the use of the tag: URI scheme [1], which appears on first blush to be a good fit. Suppose that the desired suffix of the URI is to be zzz. The URI would look like tag:widgets-r-us.org,2008:8948372837/zzz i'm 99% certain this is in the minutes from the F2F, a WUA needs to be able to instantiate multiple discreet instances of a widget, and needs to be able to distinguish them. the instances need to be distinct. Whether distinct instances should be able to enumerate and connect is not currently decided but for future improvement the scheme shouldn't prohibit this. OK, if you need to distinguish the instances, give each a different tag: URI. You could identify the instance using an entropy-generated bit string, and maintain a mapping from bit string to instance. Or, if you have some other way to designate an entity internally, such as process id + index into a table, you could put that information, or a hash of it, into the tag: URI, in combination with entropy or some other hash if you like. I hope it is clear that I'm not specifying a particular way to choose the tag: URI, as I can't because I don't know details of your requirements or architecture (sorry). The question was: Using tag: you can do just about anything you want in the way of exposing and/or hiding information (probably ten or twenty options here depending on what information and entropy feeds in and how/when/ whether it's hashed), so why not use tag: ? In other words, if you think file: and http: have problems, the tag: URI scheme might provide a way out that does not require registering a new URI scheme. You still have a design problem (which you would have regardless), but at least you avoid one source of unpleasantness. Jonathan
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Hi Jonathan, On Sat, Dec 6, 2008 at 3:21 PM, Jonathan Rees [EMAIL PROTECTED] wrote: On Dec 6, 2008, at 9:58 AM, timeless wrote: On Fri, Dec 5, 2008 at 3:42 PM, Jonathan Rees [EMAIL PROTECTED] wrote: I hate to burst ignorantly into a discussion I know little about... but that's what I'm going to do. Forgive me. Regarding the creation of local URIs for use in APIs requiring URIs: I want to consider, just as a what-if meant for clarification of requirements, the use of the tag: URI scheme [1], which appears on first blush to be a good fit. Suppose that the desired suffix of the URI is to be zzz. The URI would look like tag:widgets-r-us.org,2008:8948372837/zzz i'm 99% certain this is in the minutes from the F2F, a WUA needs to be able to instantiate multiple discreet instances of a widget, and needs to be able to distinguish them. the instances need to be distinct. Whether distinct instances should be able to enumerate and connect is not currently decided but for future improvement the scheme shouldn't prohibit this. OK, if you need to distinguish the instances, give each a different tag: URI. You could identify the instance using an entropy-generated bit string, and maintain a mapping from bit string to instance. Or, if you have some other way to designate an entity internally, such as process id + index into a table, you could put that information, or a hash of it, into the tag: URI, in combination with entropy or some other hash if you like. I hope it is clear that I'm not specifying a particular way to choose the tag: URI, as I can't because I don't know details of your requirements or architecture (sorry). The question was: Using tag: you can do just about anything you want in the way of exposing and/or hiding information (probably ten or twenty options here depending on what information and entropy feeds in and how/when/whether it's hashed), so why not use tag: ? I certainly seems like a plausible solution, as it does, on the surface, give us all the aspects that we require: 1. per-instance identity. 2. a path to files inside the package. 3. extensibility through using comas in the authority part (with the ability to identify a domain of origin). 4. no conflict with existing implemented schemes in browsers. However, reading [1] there are some outstanding issues wrt compatibility with IRIs. It's unclear if that was resolved or not in rfc4151. In other words, if you think file: and http: have problems, the tag: URI scheme might provide a way out that does not require registering a new URI scheme. You still have a design problem (which you would have regardless), but at least you avoid one source of unpleasantness. Agreed. [1] http://www.taguri.org/ -- Marcos Caceres http://datadriven.com.au
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
I hate to burst ignorantly into a discussion I know little about... but that's what I'm going to do. Forgive me. Regarding the creation of local URIs for use in APIs requiring URIs: I want to consider, just as a what-if meant for clarification of requirements, the use of the tag: URI scheme [1], which appears on first blush to be a good fit. Suppose that the desired suffix of the URI is to be zzz. The URI would look like tag:widgets-r-us.org,2008:8948372837/zzz where - 2008 is fixed by convention (knowledge of date can sometimes be a security leak) - widgets-r-us.org is any domain name permitting this use (not necessarily fixed for all time, but cooperative at least at the time of the date or year occurring in the URI) (not necessarily bearing any relation to the client) and - 8948372837 is a random number, or checksum of something (the zip file maybe? ...), that is extremely unlikely to collide with anything anywhere. This avoids information leakage. (This could just as easily be put in the domain name / email address part of the URI.) The commitment on the part of the domain holder is extremely weak: the domain name is only used to avoid collisions with other tag: URIs - no promises of DNS resolution or persistence of ownership are required. (Alternatively a similarly hands-off email address could be used.) The local software would have to know how to look these things up, but the algorithm would be pretty simple: separate the URI into its parts using a regular expression, look the archive up in a table, and use zzz to get the file inside the archive. If you don't want to create a new local registry, figure out some other identification scheme and use that in the tag: URI, again being careful not to leak any local information that shouldn't be known to components that will see the URI. -Jonathan [1] http://tools.ietf.org/rfc/rfc4151.txt
RE: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Marcos, The TAG suggested that I re-post the idea that I floated at the beginning of this thread on the new list at [EMAIL PROTECTED] and encourage any continuation of this thread to take place there - which I have now done [1]. 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. I don't know whether ...do not need to... means simply ...don't... or even more strongly ...will never have to If the possibilty 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 acccident. Stuart -- [1] http://www.w3.org/mid/[EMAIL PROTECTED] Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Williams, Stuart (HP Labs, Bristol) Sent: 02 December 2008 15:02 To: Marcos Caceres Cc: [EMAIL PROTECTED]; public-webapps Subject: RE: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn. Hello Marcos, Well, I and the TAG have expressed interest in that more general problem[3]. If you reject input on that basis you make it very hard for us to help you. Maybe our help is not what you want. No no no! I'm not rejecting any input. Honestly, I didn't mean to sound like I was. I'm sorry you interpreted my comments that way. My apologies too for any misinterpretation... lets set that aside and continue. I'll chew some more on the rest of you message... but I have other things that I need to do right now. Stuart -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England
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) [EMAIL PROTECTED] wrote: Marcos, The TAG suggested that I re-post the idea that I floated at the beginning of this thread on the new list at [EMAIL PROTECTED] and encourage any continuation of this thread to take place there - which I have now done [1]. 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. In regards to the URI leaking. Admittedly, as WebApps does not actually have any concrete proposal for a widget:// URI scheme, I honestly have not given any thought to identifiers escaping into the wild by accident. The first hurdle has been to prove that a new URI scheme is even needed. I'm not sure if WebApps has successfully even jumped that first hurdle yet. Anyway, I'm looking forward to working with everyone on addressing [3], but hopefully people will also be inclined to help us with the problem we have with widgets. Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au
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:[EMAIL PROTECTED] Sent: 28 November 2008 20:12 To: Williams, Stuart (HP Labs, Bristol) Cc: [EMAIL PROTECTED]; public-webapps Subject: Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn. On Fri, Nov 28, 2008 at 3:52 PM, Williams, Stuart (HP Labs, Bristol) [EMAIL PROTECTED] wrote: I just wanted to float an outline of a not very baked idea for trying to solve the widget referencing problem with a media-type/fragment identifer approach - those IMO being the 'right' extension point in the web architecture to be trying to use for this purpose - ie a frag id syntax to go with a new or refined media-type specification for a packaging format. One vital requirement for the packaging format is that it maintains media-types for the things that the package contains so that the whole approach can nest. This idea is inspired by (my half rememberings) of source routed email addresses where % get re-written to @ and right hand domains get eaten off of mail addresses so that say: [EMAIL PROTECTED] progresively becomes: [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] as the message is routed via example.com, somerelay.com, isp.com and finally hp.com. The approach below 'works' left to right stripping away the none fragment part of a URI and rewriting the leftmost ! in the remaining fragment with a # as one penetrates more deeply into a package structure. I don't mean to suggest that this is all properly worked out - I may have violated numerous character restrictions in URI syntax. But in principle I think something like this could meet the widget addressing (and more general thing within package addressing) problem entirely within fragID/media-type space (which then leave it properly orthogonal to URI scheme). Consider a package/containment structure as follow (where indentation represents path depth and n: [..] represents named containment). outer: [ catalog.xml scripts myScript.js lib myLib.lib aLib.lib nestedPackages innerpkg: [ catalog.xml scripts nestedScript.js deeperPkgs moreNestedPkg: [ catalog.xml scripts deeplyNested.js ... ] ] mypkg: [ catalog.xml ] ] An external reference to some target XML in the most deeply nested catalog.xml 'file' would look like this: scheme://authority/path/outer#/nestedPackages/innerpkg!/deeperPkgs/moreNestedPkg!/catalog.xml!targetXMLId Once focus shifts inside the outer package, references are re-written by replacing the leftmost ! with a # as follows: - from within outer - /nestedPackages/innerpkg#/deeperPkgs/moreNestedPkg!/catalog.xml!targetXMLId - from within innerpkg - /deeperPkgs/moreNestedPkg#/catalog.xml!targetXMLId - from within moreNestedPkg - /catalog.xml#targetXMLId Relative references within a package hierarchy work as expected. Relative Referencing more deeply into the package structure is straight forward. Relative referencing up the hierarchy is not covered by this approach, though maybe another character could be reserved to act a bit like .. but at the package hierarchy level as opposed to internal to the package - I suppose that .. itself could be allowed to take you higher than the local package root - but some detailed work would have to be put in to checking compatibility with the normalisation of relative references in 3986. The assumption here is that the package format also maintains media-type information for each of the things that it contains that all the packages, outer, innerpkg, moreNestedPkg and mypkg are marked with a media-type that defines a fragment identifier syntax and re-write rules as illustrated above. Unfortunately, widgets/zip do not maintain media-type information. That information is derived from content-type sniffing heuristics as defined in HTML5 [1]. [Aside: Hmmm process wise that would create a dependency on the publication of HTML 5 are you sure that you want to do that?] Well there are ways around that, add a package description or meta-data file either at the root of the package or at each directory level and have it carry media-type information - or use 'magic numbers' or (if you really must - in the absense of other authoritative information), sniff/guess though I think that should be the least preferred option. Anyway - that zip files don't intrinically maintain such info is not a show stopper - though I would have thought that carrying media-type information is a natural requirement
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Marcos, Stuart, On Dec 1, 2008, at 5:29 AM, ext Williams, Stuart (HP Labs, Bristol) wrote: From: Marcos Caceres [mailto:[EMAIL PROTECTED] Unfortunately, widgets/zip do not maintain media-type information. That information is derived from content-type sniffing heuristics as defined in HTML5 [1]. Well there are ways around that, add a package description or meta- data file either at the root of the package or at each directory level and have it carry media-type information - or use 'magic numbers' or (if you really must - in the absense of other authoritative information), sniff/guess though I think that should be the least preferred option. Anyway - that zip files don't intrinically maintain such info is not a show stopper - though I would have thought that carrying media-type information is a natural requirement for a packaging format for the web. It seems like adding such a meta-data file would increase the complexity of authoring and implemenation and thus be contrary to at least our Ease of use design goal [1]. -Regards, Art Barstow [1] http://www.w3.org/TR/widgets-reqs/#design
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Hi Stuart, On Mon, Dec 1, 2008 at 10:29 AM, Williams, Stuart (HP Labs, Bristol) [EMAIL PROTECTED] wrote: snip Unfortunately, widgets/zip do not maintain media-type information. That information is derived from content-type sniffing heuristics as defined in HTML5 [1]. [Aside: Hmmm process wise that would create a dependency on the publication of HTML 5 are you sure that you want to do that?] Web Apps does not have a problem having a dependency on HTML5 (particularly if the relevant section of HTML is proven to be stable by interoperable implementations). It might mean that Widgets sits on CR for 10 years, but that's ok with me at least. Sitting in CR for endless years didn't do any harm to CSS. However, if it does becomes a process problem for Web Apps, we might lift the relevant text out of HTML5 and put it in the Widgets spec. Well there are ways around that, add a package description or meta-data file either at the root of the package or at each directory level and have it carry media-type information - or use 'magic numbers' or (if you really must - in the absense of other authoritative information), sniff/guess though I think that should be the least preferred option. Right. The new proposal is that we use file extension mappings to MIME types, and if that fails, result to sniffing. We are reluctant to introduce a meta-data format at this point. For version 2 of widgets, it might be useful to either introduce the meta-data format or have an Apache-like file extensions to MIME type mapping. For example: image/gif .gif Note however, that widget engine in the wild have no problem working without MIME info. From what I have seen, they all do just fine either sniffing or using file extensions to derive the content types. Anyway - that zip files don't intrinically maintain such info is not a show stopper - though I would have thought that carrying media-type information is a natural requirement for a packaging format for the web. I'm not sure it is. When a MIME type is registered with IANA, the file extension is also registered. So one has a standardized way to derive the media type for a file by the file extension. So I guess it might make sense to have a table of common file extensions and related MIME types baked into the Widget spec for formats that the widget spec mandates support for (e.g., .html, .css, .js, .gif and so on). Other characters than / and ! could be choosen as path and container separators respective. Could this or something like it meet your requirements? If not... which ones does it fail to meet? Nice solution. But, unfortunately, widgets don't support inner packages (they inner packages are treated as arbitrary files) and we have no requirements that call for inner package access. Ok... but you answered a different question. I asked which of your requirements would an approach like this *fail* to meet? ok, sorry. I should have answered that correctly: 1. The path part of the scheme://authority/path/ does meet our requirements iff by path you mean path as defined in RFC2396 (with the ability to be an iPath as in RFC3987). 2. the scheme://authority/path is the bit Web Apps really needs to sort out. I.e., what will we call the scheme?: widget:? zip:? package:? or something else? what will be the authority? will it be the package itself: zip://myZipfile.zip? or the widget engine zip://engine/someZip.zip/? and so on... do we need an authority at all? I think these, and probably about a dozen more questions, need to be addressed before we jump the gun and start solving secondary use cases (addressing inner inner packages) I could paraphrase your response as: That would work, but it does more than we need. Dan Brickley's response[a] emphasised the need for nesting packages in packages. Even if that is not a capability that widgets would need to use, widgets could still share the same syntax. Dan's problem may be a general problem, but I need to empathize that it's not a requirement in the widget world. We could live with a shared syntax, of course. However, what worries me is bloating the scheme with features that may be rarely used, expensive to implement, and introduce another attack vector. For those reasons alone, I would like us to develop the scheme to be as simple as humanly possible and meet the most fundamental use cases/requirements ([1], [2]) before anything else. Anyway... I think that my sketch shows that there is a potential to develop a media-type + fragID-syntax based solution to the package component/widget addressing problem. Completely agreed. But can we please work on the scheme, authority and path bits first? Kind regards, Marcos -- Marcos Caceres http://datadriven.com.au [1] http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing [2] http://dev.w3.org/2006/waf/widgets-reqs/#r36.-
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
ext Williams, Stuart (HP Labs, Bristol) wrote: The assumption here is that the package format also maintains media-type information for each of the things that it contains that all the packages, outer, innerpkg, moreNestedPkg and mypkg are marked with a media-type that defines a fragment identifier syntax and re-write rules as illustrated above. Unfortunately, widgets/zip do not maintain media-type information. That information is derived from content-type sniffing heuristics as defined in HTML5 [1]. [Aside: Hmmm process wise that would create a dependency on the publication of HTML 5 are you sure that you want to do that?] Well there are ways around that, add a package description or meta-data file either at the root of the package or at each directory level and have it carry media-type information - or use 'magic numbers' or (if you really must - in the absense of other authoritative information), sniff/guess though I think that should be the least preferred option. Anyway - that zip files don't intrinically maintain such info is not a show stopper - though I would have thought that carrying media-type information is a natural requirement for a packaging format for the web. Is it not the case that a zip file containing widgets is a representation of an HTTP resource in its own right? If so, couldn't the HTTP header returned in response to a request for that resource contain an HTTP Link header [1] providing a link to another HTTP resource which provides the package metadata, including links to the individual resources contained within the zip file? Could the package metadata be represented in a common format like Atom, since it is a collection of links to other resources? Regards, - johnk [1] http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-03.txt
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
On Mon, Dec 1, 2008 at 5:35 PM, John Kemp [EMAIL PROTECTED] wrote: Is it not the case that a zip file containing widgets is a representation of an HTTP resource in its own right? no. it is not the case. a widget is a widget in its own right, there may or often may not be a similar object available from an http/https resource.
RE: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
-Original Message- From: Marcos Caceres [mailto:[EMAIL PROTECTED] Sent: 01 December 2008 15:28 To: Williams, Stuart (HP Labs, Bristol) Cc: [EMAIL PROTECTED]; public-webapps Subject: Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn. Hi Stuart, On Mon, Dec 1, 2008 at 10:29 AM, Williams, Stuart (HP Labs, Bristol) [EMAIL PROTECTED] wrote: snip Unfortunately, widgets/zip do not maintain media-type information. That information is derived from content-type sniffing heuristics as defined in HTML5 [1]. [Aside: Hmmm process wise that would create a dependency on the publication of HTML 5 are you sure that you want to do that?] Web Apps does not have a problem having a dependency on HTML5 (particularly if the relevant section of HTML is proven to be stable by interoperable implementations). It might mean that Widgets sits on CR for 10 years, but that's ok with me at least. Sitting in CR for endless years didn't do any harm to CSS. However, if it does becomes a process problem for Web Apps, we might lift the relevant text out of HTML5 and put it in the Widgets spec. Your or your WG's call. Well there are ways around that, add a package description or meta-data file either at the root of the package or at each directory level and have it carry media-type information - or use 'magic numbers' or (if you really must - in the absense of other authoritative information), sniff/guess though I think that should be the least preferred option. Right. The new proposal is that we use file extension mappings to MIME types, and if that fails, result to sniffing. We are reluctant to introduce a meta-data format at this point. For version 2 of widgets, it might be useful to either introduce the meta-data format or have an Apache-like file extensions to MIME type mapping. For example: image/gif .gif Note however, that widget engine in the wild have no problem working without MIME info. From what I have seen, they all do just fine either sniffing or using file extensions to derive the content types. Anyway - that zip files don't intrinically maintain such info is not a show stopper - though I would have thought that carrying media-type information is a natural requirement for a packaging format for the web. I'm not sure it is. When a MIME type is registered with IANA, the file extension is also registered. What is registered (RFC 4288 section 4.11) is a list of file name extensions commonly used with the media-type. It does *not* reserve the extension for exclusive use with that media-type. It does *not* prevent other arbitrary file name extension or indeed no-extension being used. So... yes not a bad hint, but nothing is certain. So one has a standardized way to derive the media type for a file by the file extension. Not with certainty... So I guess it might make sense to have a table of common file extensions and related MIME types baked into the Widget spec for formats that the widget spec mandates support for (e.g., .html, .css, .js, .gif and so on). Other characters than / and ! could be choosen as path and container separators respective. Could this or something like it meet your requirements? If not... which ones does it fail to meet? Nice solution. But, unfortunately, widgets don't support inner packages (they inner packages are treated as arbitrary files) and we have no requirements that call for inner package access. Ok... but you answered a different question. I asked which of your requirements would an approach like this *fail* to meet? ok, sorry. I should have answered that correctly: 1. The path part of the scheme://authority/path/ does meet our requirements iff by path you mean path as defined in RFC2396 (with the ability to be an iPath as in RFC3987). Which part of http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing says that? I do not see that stated as a requirement there. 2. the scheme://authority/path is the bit Web Apps really needs to sort out. I.e., what will we call the scheme?: widget:? zip:? package:? or something else? what will be the authority? will it be the package itself: zip://myZipfile.zip? or the widget engine zip://engine/someZip.zip/? and so on... do we need an authority at all? I think these, and probably about a dozen more questions, need to be addressed before we jump the gun and start solving secondary use cases (addressing inner inner packages) Ok... so I now think that we are speaking at cross purposes. I read 'widget-reqs/#r6.-addressing as stating requirements for a widget addressing scheme. I take the use of the word 'scheme' in that requirement as very general - ie. I do not specifically read it as URI Scheme, but as approach for addressing widget components. If by the use of the word Scheme in Addressing Scheme means URI Scheme which your response seems to suggest then I
RE: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Hello Art, -Original Message- From: Arthur Barstow [mailto:[EMAIL PROTECTED] Sent: 01 December 2008 15:10 To: Williams, Stuart (HP Labs, Bristol); Marcos Caceres Cc: [EMAIL PROTECTED]; public-webapps Subject: Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn. Marcos, Stuart, On Dec 1, 2008, at 5:29 AM, ext Williams, Stuart (HP Labs, Bristol) wrote: From: Marcos Caceres [mailto:[EMAIL PROTECTED] Unfortunately, widgets/zip do not maintain media-type information. That information is derived from content-type sniffing heuristics as defined in HTML5 [1]. Well there are ways around that, add a package description or meta- data file either at the root of the package or at each directory level and have it carry media-type information - or use 'magic numbers' or (if you really must - in the absense of other authoritative information), sniff/guess though I think that should be the least preferred option. Anyway - that zip files don't intrinically maintain such info is not a show stopper - though I would have thought that carrying media-type information is a natural requirement for a packaging format for the web. It seems like adding such a meta-data file would increase the complexity of authoring and implemenation and thus be contrary to at least our Ease of use design goal [1]. Surely that is a bit subjective. Folks creating widget packages are going to be tech savvy users and probably using tools that automate the process. -Regards, Art Barstow [1] http://www.w3.org/TR/widgets-reqs/#design Stuart -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England
RE: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Hello John, -Original Message- From: John Kemp [mailto:[EMAIL PROTECTED] Sent: 01 December 2008 15:35 To: Williams, Stuart (HP Labs, Bristol) Cc: Marcos Caceres; [EMAIL PROTECTED]; public-webapps Subject: Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn. ext Williams, Stuart (HP Labs, Bristol) wrote: snip/ Anyway - that zip files don't intrinically maintain such info is not a show stopper - though I would have thought that carrying media-type information is a natural requirement for a packaging format for the web. Is it not the case that a zip file containing widgets is a representation of an HTTP resource in its own right? If so, couldn't the HTTP header returned in response to a request for that resource contain an HTTP Link header [1] providing a link to another HTTP resource which provides the package metadata, including links to the individual resources contained within the zip file? In principle that's a possibility - though it provides an opportunity for more failure modes (got the package, failed to get it's metadata) - and there will be the inevitable multiple round-trip concerns, though since the headers before the body metadata retrieval could be concurrent. Could the package metadata be represented in a common format like Atom, since it is a collection of links to other resources? Plausible, though I have not looked at Atom in detail. Regards, - johnk [1] http://www.ietf.org/internet-drafts/draft-nottingham-http-link-header-03.txt Stuart -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Williams, Stuart (HP Labs, Bristol) wrote:
Well there are ways around that, add a package description
or meta-data file either at the root of the package or at
each directory level and have it carry media-type information
- or use 'magic numbers' or (if you really must - in the
absense of other authoritative information), sniff/guess
though I think that should be the least preferred option.
Right. The new proposal is that we use file extension mappings to MIME
types, and if that fails, result to sniffing. We are reluctant to
introduce a meta-data format at this point.
(Just allow RDFa+XHTML and leave it to the marketplace...)
For version 2 of widgets,
it might be useful to either introduce the meta-data format or have
an Apache-like file extensions to MIME type mapping. For example:
image/gif .gif
Note however, that widget engine in the wild have no problem working
without MIME info. From what I have seen, they all do just fine either
sniffing or using file extensions to derive the content types.
Anyway - that zip files don't intrinically maintain such
info is not a show stopper - though I would have thought that
carrying media-type information is a natural requirement for
a packaging format for the web.
I'm not sure it is. When a MIME type is registered with IANA, the file
extension is also registered.
What is registered (RFC 4288 section 4.11) is a list of file name extensions
commonly used with the media-type.
It does *not* reserve the extension for exclusive use with that media-type.
It does *not* prevent other arbitrary file name extension or indeed
no-extension being used.
So... yes not a bad hint, but nothing is certain.
So one has a standardized way to derive
the media type for a file by the file extension.
Not with certainty...
So this seems like a very small piece of metadata ('this filetree
follows the IANA filename to media type mappings') has a lot of value.
If the versions of the IANA mapping are easily identified, the metadata
becomes a URI rather than a single bit. Either way, you can gain a lot
from not a lot, I think.
cheers,
Dan
--
http://danbri.org/
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
On Mon, Dec 1, 2008 at 5:31 PM, Dan Brickley [EMAIL PROTECTED] wrote:
Williams, Stuart (HP Labs, Bristol) wrote:
Well there are ways around that, add a package description
or meta-data file either at the root of the package or at
each directory level and have it carry media-type information
- or use 'magic numbers' or (if you really must - in the
absense of other authoritative information), sniff/guess
though I think that should be the least preferred option.
Right. The new proposal is that we use file extension mappings to MIME
types, and if that fails, result to sniffing. We are reluctant to
introduce a meta-data format at this point.
(Just allow RDFa+XHTML and leave it to the marketplace...)
right :)
For version 2 of widgets,
it might be useful to either introduce the meta-data format or have
an Apache-like file extensions to MIME type mapping. For example:
image/gif .gif
Note however, that widget engine in the wild have no problem working
without MIME info. From what I have seen, they all do just fine either
sniffing or using file extensions to derive the content types.
Anyway - that zip files don't intrinically maintain such
info is not a show stopper - though I would have thought that
carrying media-type information is a natural requirement for
a packaging format for the web.
I'm not sure it is. When a MIME type is registered with IANA, the file
extension is also registered.
What is registered (RFC 4288 section 4.11) is a list of file name
extensions commonly used with the media-type.
It does *not* reserve the extension for exclusive use with that
media-type.
It does *not* prevent other arbitrary file name extension or indeed
no-extension being used.
So... yes not a bad hint, but nothing is certain.
So one has a standardized way to derive
the media type for a file by the file extension.
Not with certainty...
So this seems like a very small piece of metadata ('this filetree follows
the IANA filename to media type mappings') has a lot of value. If the
versions of the IANA mapping are easily identified, the metadata becomes a
URI rather than a single bit. Either way, you can gain a lot from not a lot,
I think.
So we are clear, what do you have in mind here?
Kind regards,
Marcos
--
Marcos Caceres
http://datadriven.com.au
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
Hi Stuart, On Mon, Dec 1, 2008 at 4:37 PM, Williams, Stuart (HP Labs, Bristol) [EMAIL PROTECTED] wrote: -Original Message- From: Marcos Caceres [mailto:[EMAIL PROTECTED] Sent: 01 December 2008 15:28 To: Williams, Stuart (HP Labs, Bristol) Cc: [EMAIL PROTECTED]; public-webapps Subject: Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn. Hi Stuart, On Mon, Dec 1, 2008 at 10:29 AM, Williams, Stuart (HP Labs, Bristol) [EMAIL PROTECTED] wrote: snip Unfortunately, widgets/zip do not maintain media-type information. That information is derived from content-type sniffing heuristics as defined in HTML5 [1]. [Aside: Hmmm process wise that would create a dependency on the publication of HTML 5 are you sure that you want to do that?] Web Apps does not have a problem having a dependency on HTML5 (particularly if the relevant section of HTML is proven to be stable by interoperable implementations). It might mean that Widgets sits on CR for 10 years, but that's ok with me at least. Sitting in CR for endless years didn't do any harm to CSS. However, if it does becomes a process problem for Web Apps, we might lift the relevant text out of HTML5 and put it in the Widgets spec. Your or your WG's call. Well there are ways around that, add a package description or meta-data file either at the root of the package or at each directory level and have it carry media-type information - or use 'magic numbers' or (if you really must - in the absense of other authoritative information), sniff/guess though I think that should be the least preferred option. Right. The new proposal is that we use file extension mappings to MIME types, and if that fails, result to sniffing. We are reluctant to introduce a meta-data format at this point. For version 2 of widgets, it might be useful to either introduce the meta-data format or have an Apache-like file extensions to MIME type mapping. For example: image/gif .gif Note however, that widget engine in the wild have no problem working without MIME info. From what I have seen, they all do just fine either sniffing or using file extensions to derive the content types. Anyway - that zip files don't intrinically maintain such info is not a show stopper - though I would have thought that carrying media-type information is a natural requirement for a packaging format for the web. I'm not sure it is. When a MIME type is registered with IANA, the file extension is also registered. What is registered (RFC 4288 section 4.11) is a list of file name extensions commonly used with the media-type. It does *not* reserve the extension for exclusive use with that media-type. It does *not* prevent other arbitrary file name extension or indeed no-extension being used. So... yes not a bad hint, but nothing is certain. Agreed. But you get the same problem with mislabeled types in HTTP. In the majority of cases the file extension will be correct. So one has a standardized way to derive the media type for a file by the file extension. Not with certainty... So I guess it might make sense to have a table of common file extensions and related MIME types baked into the Widget spec for formats that the widget spec mandates support for (e.g., .html, .css, .js, .gif and so on). Other characters than / and ! could be choosen as path and container separators respective. Could this or something like it meet your requirements? If not... which ones does it fail to meet? Nice solution. But, unfortunately, widgets don't support inner packages (they inner packages are treated as arbitrary files) and we have no requirements that call for inner package access. Ok... but you answered a different question. I asked which of your requirements would an approach like this *fail* to meet? ok, sorry. I should have answered that correctly: 1. The path part of the scheme://authority/path/ does meet our requirements iff by path you mean path as defined in RFC2396 (with the ability to be an iPath as in RFC3987). Which part of http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing says that? I do not see that stated as a requirement there. It would be overly prescriptive for us to have the solution in the requirement. The requirement basically boils down to: relative and absolute addressing (in the path-sense). This requirement is just concerned with having a path (not a full URI scheme). 2. the scheme://authority/path is the bit Web Apps really needs to sort out. I.e., what will we call the scheme?: widget:? zip:? package:? or something else? what will be the authority? will it be the package itself: zip://myZipfile.zip? or the widget engine zip://engine/someZip.zip/? and so on... do we need an authority at all? I think these, and probably about a dozen more questions, need to be addressed before we jump the gun and start solving
Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
[Resending with minor corrections and to get tracker's attention and include public-webapps] I just wanted to float an outline of a not very baked idea for trying to solve the widget referencing problem with a media-type/fragment identifer approach - those IMO being the 'right' extension point in the web architecture to be trying to use for this purpose - ie a frag id syntax to go with a new or refined media-type specification for a packaging format. One vital requirement for the packaging format is that it maintains media-types for the things that the package contains so that the whole approach can nest. This idea is inspired by (my half rememberings) of source routed email addresses where % get re-written to @ and right hand domains get eaten off of mail addresses so that say: [EMAIL PROTECTED] progresively becomes: [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] as the message is routed via example.com, somerelay.com, isp.com and finally hp.com. The approach below 'works' left to right stripping away the none fragment part of a URI and rewriting the leftmost ! in the remaining fragment with a # as one penetrates more deeply into a package structure. I don't mean to suggest that this is all properly worked out - I may have violated numerous character restrictions in URI syntax. But in principle I think something like this could meet the widget addressing (and more general thing within package addressing) problem entirely within fragID/media-type space (which then leave it properly orthogonal to URI scheme). Consider a package/containment structure as follow (where indentation represents path depth and n: [..] represents named containment). outer: [ catalog.xml scripts myScript.js lib myLib.lib aLib.lib nestedPackages innerpkg: [ catalog.xml scripts nestedScript.js deeperPkgs moreNestedPkg: [ catalog.xml scripts deeplyNested.js ... ] ] mypkg: [ catalog.xml ... ] ] An external reference to some target XML in the most deeply nested catalog.xml 'file' would look like this: scheme://authority/path/outer#/nestedPackages/innerpkg!/deeperPkgs/moreNestedPkg!/catalog.xml!targetXMLId Once focus shifts inside the outer package, references are re-written by replacing the leftmost ! with a # as follows: - from within outer - /nestedPackages/innerpkg#/deeperPkgs/moreNestedPkg!/catalog.xml!targetXMLId - from within innerpkg - /deeperPkgs/moreNestedPkg#/catalog.xml!targetXMLId - from within moreNestedPkg - /catalog.xml#targetXMLId Relative references within a package hierarchy work as expected. Relative Referencing more deeply into the package structure is straight forward. Relative referencing up the hierarchy is not covered by this approach, though maybe another character could be reserved to act a bit like .. but at the package hierarchy level as opposed to internal to the package - I suppose that .. itself could be allowed to take you higher than the local package root - but some detailed work would have to be put in to checking compatibility with the normalisation of relative references in 3986. The assumption here is that the package format also maintains media-type information for each of the things that it contains that all the packages, outer, innerpkg, moreNestedPkg and mypkg are marked with a media-type that defines a fragment identifier syntax and re-write rules as illustrated above. Other characters than / and ! could be choosen as path and container separators respective. Could this or something like it meet your requirements? If not... which ones does it fail to meet? BR Stuart -- Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN Registered No: 690597 England [Traker: this is TAG ISSUE-61]
Re: Sketch of an idea to address widget/package addressing with fragID syntax and media-type defn.
On Fri, Nov 28, 2008 at 3:52 PM, Williams, Stuart (HP Labs, Bristol) [EMAIL PROTECTED] wrote: I just wanted to float an outline of a not very baked idea for trying to solve the widget referencing problem with a media-type/fragment identifer approach - those IMO being the 'right' extension point in the web architecture to be trying to use for this purpose - ie a frag id syntax to go with a new or refined media-type specification for a packaging format. One vital requirement for the packaging format is that it maintains media-types for the things that the package contains so that the whole approach can nest. This idea is inspired by (my half rememberings) of source routed email addresses where % get re-written to @ and right hand domains get eaten off of mail addresses so that say: [EMAIL PROTECTED] progresively becomes: [EMAIL PROTECTED] - [EMAIL PROTECTED] - [EMAIL PROTECTED] as the message is routed via example.com, somerelay.com, isp.com and finally hp.com. The approach below 'works' left to right stripping away the none fragment part of a URI and rewriting the leftmost ! in the remaining fragment with a # as one penetrates more deeply into a package structure. I don't mean to suggest that this is all properly worked out - I may have violated numerous character restrictions in URI syntax. But in principle I think something like this could meet the widget addressing (and more general thing within package addressing) problem entirely within fragID/media-type space (which then leave it properly orthogonal to URI scheme). Consider a package/containment structure as follow (where indentation represents path depth and n: [..] represents named containment). outer: [ catalog.xml scripts myScript.js lib myLib.lib aLib.lib nestedPackages innerpkg: [ catalog.xml scripts nestedScript.js deeperPkgs moreNestedPkg: [ catalog.xml scripts deeplyNested.js ... ] ] mypkg: [ catalog.xml ] ] An external reference to some target XML in the most deeply nested catalog.xml 'file' would look like this: scheme://authority/path/outer#/nestedPackages/innerpkg!/deeperPkgs/moreNestedPkg!/catalog.xml!targetXMLId Once focus shifts inside the outer package, references are re-written by replacing the leftmost ! with a # as follows: - from within outer - /nestedPackages/innerpkg#/deeperPkgs/moreNestedPkg!/catalog.xml!targetXMLId - from within innerpkg - /deeperPkgs/moreNestedPkg#/catalog.xml!targetXMLId - from within moreNestedPkg - /catalog.xml#targetXMLId Relative references within a package hierarchy work as expected. Relative Referencing more deeply into the package structure is straight forward. Relative referencing up the hierarchy is not covered by this approach, though maybe another character could be reserved to act a bit like .. but at the package hierarchy level as opposed to internal to the package - I suppose that .. itself could be allowed to take you higher than the local package root - but some detailed work would have to be put in to checking compatibility with the normalisation of relative references in 3986. The assumption here is that the package format also maintains media-type information for each of the things that it contains that all the packages, outer, innerpkg, moreNestedPkg and mypkg are marked with a media-type that defines a fragment identifier syntax and re-write rules as illustrated above. Unfortunately, widgets/zip do not maintain media-type information. That information is derived from content-type sniffing heuristics as defined in HTML5 [1]. Other characters than / and ! could be choosen as path and container separators respective. Could this or something like it meet your requirements? If not... which ones does it fail to meet? Nice solution. But, unfortunately, widgets don't support inner packages (they inner packages are treated as arbitrary files) and we have no requirements that call for inner package access. Kind regards, Marcos [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#content-type-0 -- Marcos Caceres http://datadriven.com.au
