Re: Comments on Widgets 1.0: Requirements LCWD
Hi Krzysztof, 2008/11/3 Krzysztof Maczyński [EMAIL PROTECTED]: Marcos, Sorry for the delay in replying. When you wrote to me on 14 October, I was in the Near East with very occasional Internet access. I'll understand if at this moment it's to late to give my input the full weight in your process it could have had if sent earlier. Anyway, here it goes: No pros. Apologies on my part too, I've also been away on vacation for the last 3 week. Ok, I think we have been misunderstanding each other. I agree 100% with what you are saying, so I am relaxing this to a MAY. However, please understand that they reason we want file extensions is because widget are shared over communication channels other than HTTP. It's like the situation when a Mac user sends Windows users a file without a file extension... it can lead t o a lot of frustration, which want to avoid (more below). Yes, I understand this issue and I believe I have already treated it previously. But I'll try to restate my thoughts with a concrete example. The resource, when stored as a file on a file system supporting extensions as the way of indicating content types (or in some other context where using extensions in this way is the standard practice), should indeed be named with an appropriate extension. But that is a consideration principally outside the Web. I wrote that it needn't be mentioned, but if mentioning is deemed desirable, no normative specification language should apply (ideally no MUST, SHOULD, MAY or their RFC 2119 relatives). For example, assume you have a Linux system with a file ~/public_html/MyWidget.widget and you decide to publish it on the Web with HTTP. Then the default thing to do for your Web server may be to create a resource under the URI http://MyDomain.example.org/MyWidget whose representation will be the content of this file and which will be served with an appropriate Content-Type header. Conversely, if a Windows user downloads this resource and saves it on his file system, the user agent performing this (e.g. a download manager which follows Web usage of MIME and can access a mapping from MIME types to extensions registered in Windows (maintained by itself, by the default Web browser, by the browser for which the download manager is a plugin, or wherever else)) may add an appropriate extension automatically or include it as the default if the user is prompted for the file name. Your last sentence captures the intention of the usage of the file extension precisely. However, it is not a guarantee that a user agent will know what extension to apply based on the MIME type. To this effect, the spec will still recommended that the extension be .wgt (if only to guide authors for these exceptional circumstances - and completely unrelated to the world of HTTP). We by no means want to violate the TAG findings or to mandate that the file extension always be present, but we need to do our best to ensure interop once widgets leave the Web. I don't know of any other way of reducing the file extension interop problem in the spec, but to recommend the file extension and the appropriate content-type sniffing behaviors for UAs. The requirement is now simply: A conforming specification MUST specify a file name extension that authors MAY assign to widget resources in contexts that rely on file extensions, such as many popular file systems. So, it is now silent on any HTTP related matter. In the rationale, I used some of your text (last sentence): When a MIME Type is not present, as is the case when a widget is instantiated locally from an end-user's storage device, the operating system will sometimes use the file extension to associate the widget resource with the appropriate widget user agent. However, when the widget is distributed over HTTP and a MIME type is present, a file extension is not required. However, it should be noted that in some cases a Web server may rely on a file extension to correctly set a widget resource's MIME type in the HTTP headers. In addition, when saving a widget to a storage device, a user agent that is aware of the content type of widgets could add the appropriate file extension automatically or include it as the default if the user is prompted for the file name. no schema langauge exists that can capture the intricacies required to fully validate the configuration document correctly. I think you may mean assert conformance of instead of validate. Then this is a common situation with other specifications as well (yours for the configuration document seems to be going to be relatively simple, so maybe what you've written will turn out not to be even the case), especially those which have much to do with users. (There has been much effort to significantly reduce this phenomenon in WCAG 2.0, but it would be futile to try to eliminate it.) Agreed. However, the entire idea behind this paragraph seems surprising, to say the
Re: Comments on Widgets 1.0: Requirements LCWD
Marcos,
Sorry for the delay in replying. When you wrote to me on 14 October, I was in
the Near East with very occasional Internet access. I'll understand if at this
moment it's to late to give my input the full weight in your process it could
have had if sent earlier. Anyway, here it goes:
Ok, I think we have been misunderstanding each other. I agree 100%
with what you are saying, so I am relaxing this to a MAY. However,
please understand that they reason we want file extensions is because
widget are shared over communication channels other than HTTP. It's
like the situation when a Mac user sends Windows users a file without
a file extension... it can lead t o a lot of frustration, which want
to avoid (more below).
Yes, I understand this issue and I believe I have already treated it
previously. But I'll try to restate my thoughts with a concrete example. The
resource, when stored as a file on a file system supporting extensions as the
way of indicating content types (or in some other context where using
extensions in this way is the standard practice), should indeed be named with
an appropriate extension. But that is a consideration principally outside the
Web. I wrote that it needn't be mentioned, but if mentioning is deemed
desirable, no normative specification language should apply (ideally no MUST,
SHOULD, MAY or their RFC 2119 relatives). For example, assume you have a Linux
system with a file ~/public_html/MyWidget.widget and you decide to publish it
on the Web with HTTP. Then the default thing to do for your Web server may be
to create a resource under the URI http://MyDomain.example.org/MyWidget whose
representation will be the content of this file and which will be served with
an appropriate Content-Type header. Conversely, if a Windows user downloads
this resource and saves it on his file system, the user agent performing this
(e.g. a download manager which follows Web usage of MIME and can access a
mapping from MIME types to extensions registered in Windows (maintained by
itself, by the default Web browser, by the browser for which the download
manager is a plugin, or wherever else)) may add an appropriate extension
automatically or include it as the default if the user is prompted for the file
name.
no schema
langauge exists that can capture the intricacies required to fully
validate the configuration document correctly.
I think you may mean assert conformance of instead of validate. Then this
is a common situation with other specifications as well (yours for the
configuration document seems to be going to be relatively simple, so maybe what
you've written will turn out not to be even the case), especially those which
have much to do with users. (There has been much effort to significantly reduce
this phenomenon in WCAG 2.0, but it would be futile to try to eliminate it.)
However, the entire idea behind this paragraph seems surprising, to say the
least. Why write a schema, which is a machine-readable version of mostly the
same rules which are described in prose, with precise semantics specifically
crafted by authors of the schema language to facilitate expressing such rules,
and then not include it as normative?
However, I agree that contradictory to the
system is convoluted. Any suggestion of what I might change it to?
I'd probably go for unfeasible [for the user agent] or unfeasible {maybe
impossible} to realize {maybe satisfy or satisfy (realize) or satisfy or
realize} by the widget user agent.
: widget width=100-20/. I guess that is an error, but I'm just
trying to say that the author should not be punished. Should I just
drop that bit of the statement?
Yes, I believe so. It suggests being erroneously declared is some definite
condition distinguished from being in error.
HTML has to be enhanced in order to
meet the accessibility requirements
The problem is not with HTML but with scripts. And almost none of them
(particularly all written in ECMAScript et al.) would work but for the
assumption (nowhere specified, pending Window Object 1.0's progress to Rec)
that the global object implements the AbstractView interface (which includes
the crucially important document property). But I feel this is already far
enough from the present topic.
Re: Comments on Widgets 1.0: Requirements LCWD
2008/9/22 Marcos Caceres [EMAIL PROTECTED]: Ok. I see your point. However, I'm not sure what I can do as vendors won't budge on this issue for now. At the moment, ZIP serves the purpose for widgets. But as they become more popular, the limitations with Zip will quickly be exposed. Zip will either have to become more like MIME or we will have to migrate over to MIME... we will seriously need to watch the evolution of Widgets and the market in regards to this. note that BeOS w/ its BeFS used mime types for files and it supported stashing mime types into zip files, I don't remember how, but I'm fairly certain it did it.
Re: Comments on Widgets 1.0: Requirements LCWD
On Tue, Sep 23, 2008 at 4:02 PM, timeless [EMAIL PROTECTED] wrote: 2008/9/22 Marcos Caceres [EMAIL PROTECTED]: Ok. I see your point. However, I'm not sure what I can do as vendors won't budge on this issue for now. At the moment, ZIP serves the purpose for widgets. But as they become more popular, the limitations with Zip will quickly be exposed. Zip will either have to become more like MIME or we will have to migrate over to MIME... we will seriously need to watch the evolution of Widgets and the market in regards to this. note that BeOS w/ its BeFS used mime types for files and it supported stashing mime types into zip files, I don't remember how, but I'm fairly certain it did it. There is lots of ways of putting the mimetype into a zip file. For example, one could use the comment block, or do what OCF does (include a file called MIMETYPE as the first file). -- Marcos Caceres http://datadriven.com.au
Re: Comments on Widgets 1.0: Requirements LCWD
Hi, Krzysztof. Thanks again for this third round feedback. Some minor things I would like your approval on below. 2008/9/20 Krzysztof Maczyński [EMAIL PROTECTED]: Dear Marcos and other WG Members, I can see you've published another LCWD. As Anne van Kesteren wrote earlier this month, a WD gives more incentive for feedback; I believe people tend to think (at least subconsciously) of editors' drafts as something likely to be used as their personal notepads where they may feel free to mess around in any ways they like to work without being constrained by readability or other concerns which need polishing when a document goes official (at least I do). So I've reviewed it and here are some comments, followed by a reply to your mail from 9th September. Never the less, this document speaks only of a conforming specification (defined below). I'm not a native speaker of English, but shouldn't that be Nevertheless? Fixed. A conforming specification MUST specify how a widget user agent will process a widget resource that was served with an unsupported MIME type This is already fully specified in a MIME RFC, namely that it's treated as application/octet-stream. I can imagine you'd like widget user agents to override the MIME type in some cases. This could only be allowed with user consent. The consent needn't be granted each time such situation arises. It can be a configurable option of the widget user agent. You may want to make providing this option a SHOULD. But MUST be disabled by default. I believe it's the furthest that the Widgets spec can go. Maybe. But if vendors are going to do sniffing, then we might as well define an interoperable model for that. In addition, a conforming specification SHOULD recommend that a widget resource always contains a file extension, even when being sent over HTTP. As you already know, neither I, nor Web architecture gurus, led by Tim Berners-Lee, consider this a good idea. This would conflict with best practices stated in many different places, so were it a SHOULD, I'd just blame the spec and do otherwise. If you don't change your mind, I hope at least yit's not going to be a MUST in the spec. Ok, I think we have been misunderstanding each other. I agree 100% with what you are saying, so I am relaxing this to a MAY. However, please understand that they reason we want file extensions is because widget are shared over communication channels other than HTTP. It's like the situation when a Mac user sends Windows users a file without a file extension... it can lead t o a lot of frustration, which want to avoid (more below). A conforming specification MUST specify a file extension for widget resources not intended to be sent over HTTP. Let me elaborate a bit on my point of view which I claim to be more Web-centric than contemporary-PC-centric. Filename extensions are artifacts of many popular tree structured file systems which usually haven't got other reliable means (not that this one is particularly reliable, but on a local system conflicts are more manageable than on the Web) to differentiate among content types. (Windows experimented with some slender MIME provisions before XP but apparently it was abandonned, unfortunately.) They are a technicality to which users should not be exposed by default (expecting them to learn a dictionary of mostly TLAs is commonplace but regrettable). (Some OSes feature hiding extensions. I have it turned off because otherwise there's no simple way in Vista to change the type of a file. As an advanced used I'd like a UI to change the MIME type (or extension as a poor man's substitute in a MIME unaware OS), and a not significantly less simple than to change the filename (or even just as simple, but still separate, as the operation is conceptually distinct from renaming). I don't know the current state on Apple systems but it used to be similar.) Now, the ubiquity of extensions on desktops has creeped out into some other worlds, not omitting the Web. While it's mostly harmless in some more file-centric contexts (like FTP), newer Web standards (including HTTP) are designed with a completely different, more robust and flexible idea. This way it's meaningful to have default resources in HTTP directories (for URIs with paths ending in / or bare authority). More importantly, as Tim Berners-Lee described in his classical Cool URIs don't change, it allows authors to replace representations of resources with ones of different types. (If you specify Widgets 2.0 based on MIME containers, it'll have a different MIME type (multipart/widget or something), yet there will be no need to change the URI (which would break links to it from the Web, bookmarks, user agents' startup settings, etc.). An extreme example (but not unlikely, given that .swf is commonly used in URIs) would be if you had to serve your weather widget previously written in Flash at
Re: Comments on Widgets 1.0: Requirements LCWD
Dear Marcos and other WG Members, I can see you've published another LCWD. As Anne van Kesteren wrote earlier this month, a WD gives more incentive for feedback; I believe people tend to think (at least subconsciously) of editors' drafts as something likely to be used as their personal notepads where they may feel free to mess around in any ways they like to work without being constrained by readability or other concerns which need polishing when a document goes official (at least I do). So I've reviewed it and here are some comments, followed by a reply to your mail from 9th September. Never the less, this document speaks only of a conforming specification (defined below). I'm not a native speaker of English, but shouldn't that be Nevertheless? A conforming specification MUST specify how a widget user agent will process a widget resource that was served with an unsupported MIME type This is already fully specified in a MIME RFC, namely that it's treated as application/octet-stream. I can imagine you'd like widget user agents to override the MIME type in some cases. This could only be allowed with user consent. The consent needn't be granted each time such situation arises. It can be a configurable option of the widget user agent. You may want to make providing this option a SHOULD. But MUST be disabled by default. I believe it's the furthest that the Widgets spec can go. In addition, a conforming specification SHOULD recommend that a widget resource always contains a file extension, even when being sent over HTTP. As you already know, neither I, nor Web architecture gurus, led by Tim Berners-Lee, consider this a good idea. This would conflict with best practices stated in many different places, so were it a SHOULD, I'd just blame the spec and do otherwise. If you don't change your mind, I hope at least yit's not going to be a MUST in the spec. A conforming specification MUST specify a file extension for widget resources not intended to be sent over HTTP. Let me elaborate a bit on my point of view which I claim to be more Web-centric than contemporary-PC-centric. Filename extensions are artifacts of many popular tree structured file systems which usually haven't got other reliable means (not that this one is particularly reliable, but on a local system conflicts are more manageable than on the Web) to differentiate among content types. (Windows experimented with some slender MIME provisions before XP but apparently it was abandonned, unfortunately.) They are a technicality to which users should not be exposed by default (expecting them to learn a dictionary of mostly TLAs is commonplace but regrettable). (Some OSes feature hiding extensions. I have it turned off because otherwise there's no simple way in Vista to change the type of a file. As an advanced used I'd like a UI to change the MIME type (or extension as a poor man's substitute in a MIME unaware OS), and a not significantly less simple than to change the filename (or even just as simple, but still separate, as the operation is conceptually distinct from renaming). I don't know the current state on Apple systems but it used to be similar.) Now, the ubiquity of extensions on desktops has creeped out into some other worlds, not omitting the Web. While it's mostly harmless in some more file-centric contexts (like FTP), newer Web standards (including HTTP) are designed with a completely different, more robust and flexible idea. This way it's meaningful to have default resources in HTTP directories (for URIs with paths ending in / or bare authority). More importantly, as Tim Berners-Lee described in his classical Cool URIs don't change, it allows authors to replace representations of resources with ones of different types. (If you specify Widgets 2.0 based on MIME containers, it'll have a different MIME type (multipart/widget or something), yet there will be no need to change the URI (which would break links to it from the Web, bookmarks, user agents' startup settings, etc.). An extreme example (but not unlikely, given that .swf is commonly used in URIs) would be if you had to serve your weather widget previously written in Flash at http://example.org/weather.swf.) Of course having two systems which aren't fully compatible (popular file systems and the Internet) creates two points at which the incompatibilities should be dealt with. One is saving a widget resource to your file system. It's reasonable to expect that the user agent will offer the appropriate extension by default. The other is when a file is published on the Web. Authors are already aware (and much outreach and education effort has been spent on it for several years) that this includes two most important things: minting the URI and assigning a MIME type. Web servers have significantly improved in being easily configurable to provide good defaults when automatically publishing files in some selected directory tree as
Re: Comments on Widgets 1.0: Requirements LCWD
Hi, Krzysztof. Apologies for the delay in response (and for the length that this email has grown to!). I believe I have managed to address all your comments and integrated almost all of your new proposed text into the Req doc. Note, however, I'm currently traveling so I've been unable to check in the latest draft of the Req doc (there is a serious lack of free-wifi in Lisbon!:)). Detailed comments below... for the sake of the disposition of comments, can you please confirm if you feel the WG has addressed all your comments in a satisfactory manner. Doing so will help us to complete the Last Call process in a timely manner. Thanks! 2008/8/21 Krzysztof Maczyński [EMAIL PROTECTED]: Hi, Marcos! I'll look that up. In the mean time, it would be really helpful if you could tell me any place in particular where I've used the terms incorrectly? Actually, IRI reference isn't used anywhere at the moment. The difference is that an IRI is an identifier, and thus necessarily absolute. IRI references can be relative or absolute, in the former case there is a standard algorithm for translating them into IRIs, given a base IRI (which may be determined by any externally defined means). (Even more precisely, this holds for URIs (e.g. the term base IRI isn't probably formally defined), but the case is analoguous. IRIs just add a thin layer of syntactic sugar.) Example of misuse: For example, bootstrapping could occur by referencing, via a relative IRI the, the initial resource (Also note a typo.) Got it and fixed. FYI, I've re-read rfc3986 in light of our discussing (it has been a while since the last time I read it... it also explains why it took me a bit longer than normal to reply to this email :)). Should there be a requirement (probably only may or should for the first version) to specify some way of exposing custom APIs on instances of a widget (like XBL bindings do)? Hmm R30 was supposed to cover this (and from my reading, I think it does). Can you recommend some additional text or a change to that requirement that would satisfy what you mean? Now I understand better what it means. I thought it was about the ability to call some API provided by the client. What I wrote was that a widget could expose a custom API of its own, callable by the environment or its other inhabitants (of particular interest are other instances of the same widget, since they actually know, without any discovery, what the API is; R33 seems related, but I don't know the mechanism you envision for it). Still, I think the current requirement is more limited (maybe purposefully? if so, what's the rationale?) in that it provides only for plugging a widget instance as an implementation of some existing API which the environment (possibly on behalf of its other inhabitants, just passing their calls; although not mentioned, it's also not forbidden) is supposed to know in advance and call with built-in awareness of semantics. I mentioned similarity to XBL to emphasize that the exposed API could be arbitrary. Ok, I think I'm also getting a better perspective of where you are coming form. However, I think you are getting a bit ahead of what the WG want inter-widget communication to be. I guess what we want to specify an equivalent to HTML5 cross-document messaging for widgets. So, we don't want to expose APIs from one widget to another, we just want to define some kind of secure mediator channel that allows widgets to pass messages. We currently have a few ideas about how this will work, but we have not begun any formal work to address this requirement... (Personally, although I can see the usefulness for this features, I see cross-widget communication as fairly low priority for the working group for Version 1.0... so I would be surprised if this makes it into the spec at this point.) We don't address embedding of W3C Widgets using embed or object. Do you imply that it's impossible to have a conforming implementation which implements widgets embedded with object elements (or its equivalents from other namespaces)? Or is it discouraged? I certainly don´t think it's impossible, and I won't go as far as to discourage it. However, I would say to implementers to proceed with caution or participate in the working group to resolve the security and privacy issues around embedding widgets in web pages. FWIW, we have members in the WG who want to enable this to happen. A widget may run as a stand alone application (meaning it can run outside of a Web browser), or may be embedded into a Web document. This fragment suggests the opposite. I'm happy with this and just suggest adding a reference to Widgets 1.0: The Widget Landscape (Q1 2008) in the place where web widgets are mentioned to avoid confusing people like me who didn't know what gadgets were (and the name web widgets suggests something else to me than it actually means). Ok, two consequences from your comments: 1.
Re: Comments on Widgets 1.0: Requirements LCWD
W dniu 15 sierpnia 2008 06:05 użytkownik Marcos Caceres [EMAIL PROTECTED] napisał: HI Krzysztof, Just a friendly reminder that we (WebApps) are waiting for you to respond to the LC comments. Can you please let me know either way if you are planning to respond or not. If you are, I would really appreciate your feedback by mid next week. I hope to be able to send it today. If not, tomorrow is the very latest.
Re: Comments on Widgets 1.0: Requirements LCWD
Hi Krzysztof, I've made most of the changes you recommended but I was not able to resolve everything. Please see below. I would really appreciate if you could take the time to help me resolve outstanding issues. However, if you are happy with leaving things as they are, please let me know so I can close this thread in the disposition of comments. 2008/7/26 Krzysztof Maczyński [EMAIL PROTECTED]: Dear WG, I have written my comments below. Please take into account the difference between IRI and IRI reference defined in RFC 3987. I'll look that up. In the mean time, it would be really helpful if you could tell me any place in particular where I've used the terms incorrectly? Should there be a requirement (probably only may or should for the first version) to specify some way of exposing custom APIs on instances of a widget (like XBL bindings do)? Hmm R30 was supposed to cover this (and from my reading, I think it does). Can you recommend some additional text or a change to that requirement that would satisfy what you mean? email checkers s/email/E-mail fixed (but kept E in lowercase, which, according to wikipedia, is ok). This document does not address the requirements of web widgets, such as iGoogle Gadgets or Windows Live Gadgets. Why not? Aren't they similar enough to be covered by one set of specs and one requirements document (perhaps with a bit of inline tailoring)? No. Web widgets are just iframes or divs: They are not packaged or use widget-specific APIs. Hence, they are covered by HTML4 and HTML5. Please see section 3.1 of the Widgets 1.0 Landscape document [1] for a detailed discussion on this issue. We don't address embedding of W3C Widgets using embed or object. We might leave that for version 2.0. A conforming specification is one Not necessarily, since you plan to have 4. Should it be called conforming set of specifications? Yeah, probably. But it's not so much that all the specs need to address the one requirement (although it is true that some requirements are addressed by the interplay of multiple specs, eg. digital signatures). So even though I agree with you, and technically you are correct, I think it's pretty clear what we mean here. Also, the Widget specs are split into multiple specs for ergonomic reasons, not technical reasons: we figured that having lots of little specs are easier for people to read/review, then one monolithic one. Hopefully you (and others) can live with conforming specification. a widget resource should be easy for authors to create without requiring special software This is why ZIP (or whatever ends up decided upon) compression should be optional (also see below). Deflate is implemented in all common Zip implementations. However, it might be good for me to document the use of Deflate in the Widgets Landscape document. In the Landscape document, I have documented that all widget user agents support Zip and Deflate, but not that all operating systems support the creation of Zip files that make use of deflate. Furthermore, I don't envision taking advantage of the Security design goal by a typical author when creating widgets without special software. To be clear, are you saying that an author will need special tools to make use of the the security features? If you are, then it is too early to say that yet. For example, generation of digital signatures *may* require specialized software, but we are working hard so this is not the case. There is open source software that can generate a (XML) digital signatures from a bunch of files and folders. See for instance, http://www.aleksey.com/xmlsec/index.html. R1. Packaging Format There are arguments for enabling compression, and ZIP is discussed on the list. I'm in favour of it as long as it's optional, i.e. there can also be uncompressed widget resources. R10 satisfies this, but uniformity between these two forms should be maximized. Is Store method of ZIP considered? It fails the previous quote. MIME features (Content-Transfer-Encoding comes to mind) then? Agreed. You'll be happy to hear that support for Stored is specified in the Widgets Packaging spec. I've altered R11. Data Compression to read A conforming specification SHOULD recommend a packaging format that supports both uncompressed data and OPTIONAL data compression. R2. File Extension It seems contrary to AWWW (see also Cool URIs don't change by Tim Berners-Lee). In what sense is this contrary to AWWW? locally, widget resources are treated as files not as `representations of resources'. Eventually a widget ends up on a server where it enters the URI space (and where they can follow the URI rules/concepts and AWWW). If giving a file an extension violates AWWW, then every .html, .css, .gif, .png, etc. file also violates AWWW(?). However, I may be misunderstanding what you are trying to say here about R2:) Also, how Device independence design goal is interpreted to support this? I see no
Re: Comments on Widgets 1.0: Requirements LCWD
Hi Stuart, All, This email is a continuation of the discussion about the Widget URI scheme we've had in the past [1]. WebApps is trying to draft the final text for the Widget Requirements document regarding a URI scheme for widgets and we would again appreciate some input from the TAG. WebApps WG believes that we share similar (if not the same) objective to resolving the TAG's issue number 61 (URI Based Access to Packaged Items) [2]. Regarding URI based access to packaged items, the Widgets 1.0 Requirements document [3] contains the following Requirement: -- R6. Addressing Scheme A conforming specification MUST specify or recommend an addressing scheme to address the individual resources within the widget resource at runtime. The addressing scheme MUST be able to address individual widget instances, while potentially allowing widgets to address each other. The addressing scheme MUST NOT expose the underlying file system to the instantiated widget and an instantiated widget MUST NOT be able to address resources outside the widget resource via the addressing scheme. The addressing scheme SHOULD be one that web authors would feel comfortable using or to which they are already accustomed. Motivation: Ease of use, compatibility with other standards, current development practice or industry best-practices, security. Rationale: To allow resources to be resolved and normalized within DOM attributes. To make it easy for authors to address and load resources into their instantiated widgets, either declaratively or programmatically. For example, addressing a resource via an IRI (e.g. img src=images/bg.png'/ where the src attribute resolves to something akin to widget://myWidget/images/bg.png)). --- However, Krzysztof Maczyński has suggested we change the text above based on the following reasoning: On 2008/7/26 Krzysztof Maczyński [EMAIL PROTECTED] wrote: must not be able to address resources outside the widget resource via the addressing scheme Such ability may be useful (in some future version or even in this one), although I can see the concerns. But it seems harmless, for example, to use URNs (with semantics handled by widget user agent, such as accessing the default instance (forms in older versions of VB have those) or some operating environment motives and artifacts - these are outside the widget resource, right?). I presume there will be places where IRIs unconstrained by this addressing scheme can be used to allow such usage. Still, I think this must not cannot be enforced syntactically without disallowing relative IRI references (and I can see no reason for disallowing them). Another issue with this is that other instances of the same widget are themselves resources outside the widget resource (but not widget resources). Even though R5 currently only provides for addressing resources contained in the widget resource associated withj a given instance of the widget, I believe the goal is (or should be) to enable addressing the instances themselves as well. I would therefore suggest the wording given below for the entire paragraph. Also please clarify that addressing scheme means some recipe for minting URIs, not necessarily a URI scheme (which may or may not result from ongoing discussion as the best solution). -- A conforming specification must specify an addressing scheme (a new URI scheme or some prescribed use of an existing one) which must or should be used to address at runtime the individual resources within the widget resource in association with the current or another instance of the widget, as well as these instances themselves. This does not preclude allowing use of arbitrary IRI references in some contexts defined by a conforming specification. When the addressing scheme is used, the widget user agent must be required not to expose any other resources to the widget instance. For this purpose a conforming specification may require that accessing resources identified by IRIs using the addressing scheme which leave the allowed space described above must fail. If addressing resources outside the allowed set described above is possible with the addressing scheme, determining that this is the case for a given IRI reference should be easy for the author, at least for absolute IRI references. The addressing scheme should be one that web authors would feel comfortable using or are already accustomed to. Any thoughts or comments from WebApps members or the TAG are welcomed. [1] http://lists.w3.org/Archives/Public/www-tag/2008May/0121.html [2] http://www.w3.org/2001/tag/group/track/issues/61 [3] http://dev.w3.org/2006/waf/widgets-reqs/#r6.-addressing -- Marcos Caceres http://datadriven.com.au
