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.)
>> 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. > 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? > 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). > Please see section 3.1 of the Widgets 1.0 Landscape document [1] for > a detailed discussion on this issue. The web widgets described there are a different kind of animal indeed. I think they're irrelevant (and if mentioned at all in that document, their irrelevance deserves emphasizing, in my opinion, not to introduce confusion), because from the Web point of view they materially don't exist at all. They are real only for a server-side technology, and it's the server's private business how it generates representations of resources (entire (X)HTML documents in this case). > Hopefully > you (and others) can live with "conforming specification". I believe that a single specification can still be conforming if either of the two holds: 1. It references the other specifications normatively. 2. It says that a conforming implementation must satisfy certain conditions which entail the remaining requirements from Widgets 1.0: Requirements. It would mention conforming as well to the other specifications (referenced informatively) as one such possibility. I'm in favour of 2. >>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. By special tools you seem to mean proprietary tools. When I read the statement of the Ease of use design goal and R3's point of not requiring the user to recreate the widget resource, I assumed everything beyond a text editor was a special tool. This also caused my reaction to requiring ZIP and being unable to place contained resources outside, at an arbitrary URI (where it could be edited without recreating the widget resource, possibly only replacing the signature of the whole widget), and reference them from the widget resource as only logically contained in some "directory" (that's why I advocated MIME which has such capabilities). > In what sense is this contrary to AWWW? locally, widget resources are > treated as files not as `representations of resources' You're right, but how they're treated locally (i.e. on a typical server, or in the client's file system, which sometimes happens to be a logical equivalent of the server) is IMO irrelevant. On the Web we have only representations of resources, not files. > If giving a file an > extension violates AWWW, then every .html, .css, .gif, .png, etc. file > also violates AWWW(?). Giving it to a _file_ cannot violate anything on the Web - these are separate worlds. (And this fact also makes specifying such things out of scope for Web standards.) Retaining it (be it ".html, .css, .gif, .png, etc.") in a URI is something I (following Tim Berners-Lee, AWWW and my own nose) do oppose. > In reality, vendors will > probably sniff and they will have to sniff or use the extension any > time they get a widget from local storage or over bluetooth or other > non-MIME means or where MIME is not supported. Some MIME-aware file systems do exist. I'd like to see more MIME support in scenarios like exchange over Bluetooth or whatever, since it is more powerful and orthogonal (a good thing) to naming. But when no content type can be determined by means designed for this purpose (and only in such circumstances), sniffing by name (e.g. extension) or content inspection is architecturally sound and safe, as stated in http://www.w3.org/2001/tag/doc/mime-respect which declares what RFC 2616 defined for HTTP as univerally applicable. And by Device independence as a design goal supporting this do you mean that not supporting MIME is a possible limitation of devices? How are they supposed then to navigate to http://www.w3.org/TR/widgets-reqs/ (note lack of extension - the right thing) and interpret the response body as XHTML? > I disagree. This would be going against the grain of what widget > engines currently support: Zip. Also, there is no tool support for > MIME in the widget space or included in operating systems. All Widget > user agents support Zip and developers are well accustomed to working > with Zip. Switching to MIME would require specialized tools to be > developed just for widgets. I don't see any advantage MIME has over > Zip. As I've already written above, I can understand now why you disagree. The should part of R3 cannot be satisfied with ZIP though, I'm afraid (unless you don't consider zipping everything together again to be recreating). It also free from the issue of being a proprietary technology (I haven't had the time to follow the list closely recently; maybe you've come up with some idea). It's true that e.g. newer versions of Windows have support for ZIP and not for advanced MIME, but I wouldn't be so sure about Unix systems. MIME has a standard (meaning that generic tools and techniques can be leveraged) functionalty for all of R3 and significant portions of other requirements, whereas for ZIP you define and additional layer of semantics specific to widgets (and e.g. run into trouble with addressing inside archives). These are advantages of MIME over ZIP I can see. But I'm convinced that it probably may be possible to produce a sensible recommendation embracing current practice, i.e. ZIP. And implementors will be much more willing to comply. So I don't object to proceeding the ZIP way, but I ask that this decision be made in the specification for widgets, not hard-coded in the requirements, to allow anybody to produce (perhaps in a context completely different from where such widgets are used nowadays) a MIME-based specification and claim its conformance to this requirements Recommendation (that's why it will be a Rec, not a Note, after all). Maybe by 2.0 the landsape will have evolved in a direction where interoperability between these approaches could emerge. <rant> It would be nice if some technology gaining widespread use popularized advanced MIME features (e.g. having some parts of multipart entities stored internally (but still addressable) and some as external bodies and referenced with arbitrary IRI references) introducing them into the mainstream. Fostering interoperability is the key to realizing the, largely unused currently, vast potential MIME has thanks to the technical merits of its own, both on the Web and within local systems. Widgets could have fulfilled this role, but they went the suboptimal ZIP way instead. So to those who agree with my POV on this: it seems that again we'll have to wait. </rant> Or actually, why a Rec, not a Note, like other requirements documents? > A > conforming specification MUST specify how to process a widget resource > that was not served with the appropriate MIME type. Sounds suspicious to me. This sentence doesn't state the addressee of such requirement. Is it a widget user agent or a user agent in general? Since this spec seems to only ever mention the former, I assume it to be the case. But what's the difference, actually? And under what circumstances is it possible at all that a widget user agent is commanded to handle a resource whose MIME type (served by HTTP or inferred (possibly only conceptually, behind the scenes) by an appropriate mechanism recognizing extensions coupled with local file system) says it's not a widget or whose MIME type is absent? I think the term widget user agent deserves a clearly distinguished definition. I suggest the following: -- Definition The runtime environment having as its purpose running widgets is referred to as a widget user agent. This may be the specific purpose of this user agent, which is evident to the user, or it may be a mode of operation of a more generic user agent (e.g. a Web browser) when processing a resource. Note This document includes (link to R12) specific additional requirements concerning when a generic user agent enters this mode and acts as a widget user agent (with a built-in functionality, with a plugin or using an external programme). -- Also please replace the above sentence with: "A conforming specification MUST specify how a widget user agent processes a resource whose MIME type is unspecified." There are 3 outstanding changes: 1. Clarification that it's a widget user agent that's supposed to fulfill this. 2. The resource isn't called a widget resource. When there's no MIME type, it's just a resource, of an unknown kind. The process, allowed only in this case, of guessing an appropriate MIME type is called sniffing. 3. It's explicitly stated that the MIME type must be missing. There is no such thing as a "present but inappropriate" MIME type. (Not even when http://example.net/x.svg (seems to be an uncool URI) is served as audio/basic.) Now the rationale. I assume that this is all about sniffing, and not only allowing it in the only situation when it's allowed (as that wouldn't need any requirement), but also saying something normative about how to do it. Moreover, you seem to want to go beyond the two things Authoritative Metadata mentions as possible inputs to the optional (you want to require more and make it normative) sniffing algorithm, namely the URI and the content. The TAG Finding doesn't explicitly forbid other inputs, but I'm not sure (somebody from the TAG, if you're reading this, please evaluate this potential "heresy" and correct me if I'm wrong) if the mode of operation (i.e. a user agent induced into acting as a widget user agent) could be allowed. If it could, I believe some limitations should be put on when a user agent may enter a different mode (which influences its subsequent sniffing behaviour). (Otherwise pretty much anything would be formally allowed (even though going against the grain, spirit, intent, call it what you like, expressed in the standards), and there are people who almost certainly would pursue truly regrettable developments based on this precedent, which is after all what we're about to set.) The most important one is that when an IRI reference is passed to a generic user agent out of context (as, e.g., entered by a user in the address bar), it must not (regardless of any supposed "filename extension" in it) trigger any special operation mode. On the other hand, the user may be provided with a free choice to induce the user agent into any mode (i.e. "I want you to treat the following as a widget"). Note also that the problem is only with generic user agents, capable of handling other MIME types as well. A widget-only user agent has basically only two options: process a resource as a widget or decline processing (obligatory if a MIME type is present but unsupported) (again, the user may be consulted before making this decision, when one is warranted). The rule of thumb seems to be that any kind of management of modes in a generic user agent is allowed only with user consent, either provided explicitly or implied when he's informed with some unambiguous guise. There should be a note to this effect under R12 or in the widgets spec itself. <rant> I'm not particularly happy about adding sniffing factors and in general about specifications mandating rules for sniffing. This is a hideous feature and I suggest dropping it unless it's too late (as probably in the HTML case, unfortunately) and interoperability in such erroneous cases is required. (I don't think it is, as the implementations are quite young and not interoperable at all as of now, are they?) Since it's imposing less, not more, on implementors, there's a chance they won't care. Nevertheless, should including something like this be necessary, I've tried to do my best to write it in an architecturally sound way. (But, as mentioned above, I'm not strongly convinced it actually is. There may be a trap I've overlooked. So if you want to put this in, please have it rubberstamped by the TAG.) </rant> > (of course, I still think JSON output would be more useful;-)) RDF is a conceptual model, JSON is a serialization. They're at different levels, and don't exclude each other - see http://n2.talis.com/wiki/RDF_JSON_Specification for example. > I think we > will add this if there is more demand from developers for it. The > range of metadata elements currently covered by the spec represent the > intersection of all commonly appearing metadata elements in other > widget user agents (again see the Widget Landscape document). It'd be optional to use anyway, so little cost. Much better than realizing afterwards that the limited set of metadata turns out to be too narrow. People are starting to do inspiring things commercially in semantic technologies nowadays. So I raised this to make sure widgets are prepared to participate. > No, the intent is just to have clearly defined processing rules and > predictable behavior. But why is it desirable to have this feature in the first place (regarding R15. Copyright Notice and License Metadata)? If the primary added value of this processing would be to disable the user from using the widget or limit his possibilities of doing this, it can be easily circumvented (unless all or some of the widget resource is encrypted - a case not considered here). Or is there another important reason? And one additional question about: > how this data must be processed by a widget user agent. Wouldn't you rather envision meaningful processing of it by the server (or proxy)? > "For widgets that make use of a rendering context, a conforming > specification SHOULD specify an OPTIONAL means for an author to > declare the initial visual dimensions for an instantiated widget in a > way that is device independent (e.g. via CSS pixels). A conforming > specification MUST specify that styling by the author takes precedence > over dimensional values declared in the configuration document or any > dimensional values implicitly computed by the widget user agent.." Are there widgets which don't use any (not necessarily visual) rendering context (i.e. implement some under-the-hood services, without a user interface, visual or not)? Probably yes. I'd add "rendered in visual or tactile media" after "instantiated widget" (because in other media those dimensions aren't applicable) and replace "initial visual" with "intrinsic". Also the phrase "by the author" is obviously undesirable. > changing > "file" to "resource" here won't make too much of a difference. Just for consistency. >>> may specify an automated model >> Combined with the previous requirement this means that a spec just may >> define something that it must require the agent to do. Not that it couldn't >> possibly make sense, but if it does for some reason, please state it. Still unanswered. > What do you recommend we do here? With ZIP indeed you don't get anything beyond a filename and path (that further shows ZIP lacks featured desirable on the Web). I suggest doing nothing. The widget won't run. Its creator will surely notice it when testing. But this reveals another bunch of issues. How are MIME types and roles (like being the configuration document, if it's included in the archive (as there must also be an option to have it separately per R23)) assigned to the contained resources? Can a configuration document enumerate the contained resources and provide MIME types and possibly roles for them? In absence of a configuration document (which is optional) how can anything of particular interest be determined about the contents of the ZIP archive? When contained resourced without an assigned MIME type are accessed and no information on the link (like hreftype) provides it, is sniffing the only available resort (now I can understand better why you want to specify it; but it's within the widget resource and here more special processing can be applied than would be architecturally sound on the Web at large)? If a bare ZIP archive (labelled with a widget MIME type) not containing a configuration document (which is expected at a fixed path and filename?) is thrown at a widget user agent, I suggest that the user agent be allowed to select any of the resources in the root directory within the archive and the specification should say that there should be only one in such case (and the type is application/xml - specific processing to be possibly determined when a namespace is recognized). If you really must search by name, be it "index", and if you feel you (or implementors) can't live without <index?*> (regular expression), allow the user agent to pick any with a matching name. Explicit mention of extensions would be detrimental because of recommending something harmful. > No. Everything we have looked at is overly complicated. I guess the > closest thing in regards to r26 is HTML5's storage mechanism. Could you just list the technologies you considered, to have them in one place? And HTML5's roadmap has reaching Rec in 2020, so it's not a very good supporting spec of the compatibility with other standards design goal. > "A conforming specification MUST define a set of states in the > lifecycle of the instantiated widget. Changes in states MUST have > associated events which can be consumed by event handlers, such as > scripts. Additionally the API MUST expose the current state. A > conforming specification MUST NOT require the widget user agent to > send events to the widget immediately, and SHOULD allow the widget > user agent to dispatch the events at its convenience." > > Is that ok? Yes. I'd just add "as well as how and when an instantiated widget enters each state" at the end of the first sentence, as now it literally mandates only an unstructured set. > Hmmm... I'm concerned that you are surprised. Have I have left some > conceptual gaps in the spec? Do I need to explain things a bit more > clearly in the introduction? Please let me know what you think I > should do. Well, I assumed too much when I read R5. It just didn't occur to me that you envisioned a single scheme, for addressing instances of any running widgets as well as contained resources within the widget resource of the current instance. These seem to be quite different by nature. (It may be that you want a single scheme because in fact (though unstated) you want to enable even more: addressing contained resources in context of any instance of any widget resource instantiated in the same agent (or domain (not in the DNS sense, rather like application domain in .NET), if the agent enforces some partitioning).) > I response to your question, it is not assumed that only instances of > the same widget can be addressed with the widget scheme. Having said > that, cross-widget communication is a bit gray ATM and I would > personally like to see it removed from version 1.0. Having said that, > I'm not sure how to proceed here. WG discussion, I guess. If it happens, please input my above brainthunder (item in brainstorming ;-)). >>> The declared interface may also be accessible to screen readers >> At least should, I suggest. Also see the rationale. > > Ok, changed it to "should". I wrote at least. But since then I've reconsidered, based on an interpretation of should I've come across and assimilated. Shoulds are for things without which the product is still usable, albeit maybe with a limited functionality. Accessibility to screen readers is indispensable sometimes. As failing to meet this requirement would effectively block some users, I request that it be a must. Marcos, in my opinion you're an editor very responsive to comments, including critical ones. You put much effort into maximizing the quality of the produced specification, which I've come to appreciate even more as I shared some of it writing my 3 detailed reviews with fragments of suggested text. As a Web user, one of the many, I feel incited to express gratitude for your work. Thank you.
