- From: Mark Baker <distobj@acm.org>
- Date: Fri, 10 Oct 2008 13:37:08 -0400
- To: "Marcos Caceres" <marcosscaceres@gmail.com>
- Cc: public-webapps <public-webapps@w3.org>
On Thu, Oct 9, 2008 at 6:57 AM, Marcos Caceres <marcosscaceres@gmail.com> wrote: >> But I wonder whether the scheme really matters very much. What kind >> of intra-package references do you expect to be able to resolve? Will >> they all be relative, or will there be absolute ones? If it's just >> relative references, then any hierarchical one will do, as the >> consuming user agent can just mint their own base, be it an http URI, >> a file URI, or otherwise. > > We use both relative and absolute URI references, and the base is > derived from the i18n model we have introduced. Ok, I see that, but I don't see why you'd want to then use absolute references in the widget content. Is it your intention that widget authors would have knowledge of the base URI (or the algorithm)? From my POV, you'd want them authoring links to other widget parts using only relative references, like ZIP and all other packaging formats I know of do (at least those supporting hierarchical containment). > Personally, the solution I keep coming to is something like : > > widget-uri = "http://" widget-engine [":" instance-id] "/" > package-name path-absolute ["#" fragment] > > Where widget-engine is something akin to using, say, "localhost", but > uses some arbitrary string that identifies the engine (e.g. > theFooEngine). The optional instance-id would be a string that > uniquely identifies a widget instance for the purpose of cross-widget > communication. However, I can foresee that there may be problems with > thieving http's port semantics to uniquely identify an instance (so we > leave this out until version 2). The scheme would only support GET > requests. For example, > > http://theFooEngine/barWidget.wgt/index.html#welcome Or just http://localhost/theFooEngine/barWidget.wgt/index.html#welcome ? Mark.
Received on Friday, 10 October 2008 17:37:52 UTC