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 <1981km@gmail.com>:
> 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. The specification clearly needs renaming to avoid further confusion
by the public and those participating in the W3C. Web Apps makes the
assumption that most people don't get passed the title, and, if we are
lucky, the first sentence or two of the abstract. I suggested as a new
name "Widget Packages and User Agents 1.0: bla bla bla". Hopefully
this new title will evoke connotations beyond "web widgets" or at
least motivate (confuse?) the reader to wonder what the hell we are
doing and read on a little bit more :)

2. I´ve modified the definition of widget in the introduction to say
something like "it is envisioned that one day the widgets as being
standardized by this effort will be embeddable into Web documents".

>> 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.
>

I agree 100% and you've phrased the difference very bluntly (which is
great). It's been hard to for me to get people to understand just how
irrelevant web widgets are from a technical standpoint. Technically
speaking, on the Web, they are just a recognizable UI design pattern.
However, other groups, such as OAA have a view that the design pattern
and development approach for web widgets can be "standardized".

>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).
>

Exactly.

>> 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.

This happens already where necessary. For example, one aspect of
processing is defined by one spec and another aspect by another...
such as the dependency that packaging spec has on the digital
signature spec.

> 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.
>

The requirements are not on conforming implementations, they are on
the specification. I think what will happen is that at the end of each
section in the specs, I will put something like "this section
satisfies requirement X of the Widgets 1.0 Requirements document".
That way, each section of each conforming spec can be traced back to a
requirement. I'll also note where a requirement is met by the
combination of multiple sections of two or more specification.

>>>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.

That is more or less correct... but the don't necessarily have to be
proprietary.

>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.
>

What I had in mind when I wrote this was Window´s XP capability to
read and write to zip files like they are just normal folders.

>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).
>

Understood. I imagine we will investigate MIME as a possible
alternative packaging format in V2 of the spec. However, given that we
want to finish the packaging spec by October this year, we are going
to stick to Zip for now.

>> 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.
>

Agreed. I´ve tried to use resource as much as possible except for any
instances where it made more sense to talk about the notion of a file.
However, I´ll continue to rationalize everything in terms of resources
(particularly in the specs).

>> 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.
>

Ok, you are absolutely right. I understand now more clearly what you
are saying and proposing. Unfortunately, for widgets, the engine is
not yet designed to serve widgets like a web server, but more like
file system... Timbl also proposed that we should migrate the a server
style HTTP URI scheme, but I argued that this would significantly
complicate widgets 1.0 implementations. I argued that we should make
this a goal to migrate to a HTTP-based URI scheme in the future. FWIW,
I also wrote a blog entry about this last year:

http://datadriven.com.au/2007/12/17/omg-im-a-server-widgets-and-the-exciting-future-of-mobiles/

>> 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?
>

The lack of support for MIME applied only to the widget package (once
the start file is loaded into the browser, normal HTTP browser
functionality resumes). Again, if a widget engine acted like a web
server, serving things would not be a problem because then the engine
could serve itself files in accordance to MIME. Again, this emphasizes
the need for the migration to HTTP to happen, but like I said above,
this adds too much complexity to version 1.0 of the Widget spec. What
we would need to do for a reference implementation is effectively
merge Apache + Webkit + our custom APIs. I guess we (WebApps) need to
make sure we don´t screw up the architecture and allow either:

1. the extension of the "widget:" scheme to behave like HTTP in v2.
2. the evolutionary deprecation of "widget:" and a migration to "http:"
3. have the courage to use HTTP for version 1.

Although I've personally pushed for 3 in the past, it's just too
complex for now. I think 1 is what is needed going forward: the custom
widget specific aspects of the "widget:" scheme (if any), with the
added power of HTTP.

>> 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).
>

No, zipping tools are perfectly happy to support this functionality.
This might not be possible with simple command line tools, but other
freely available tools do this quite happily (e.g. Window´s compressed
folders: i can add, delete, replace files, etc.. without recreating
the archive).

> 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.
>

We haven't come up with anything new. I want to say this generally to
everyone reading this:

As the WG understands it, it seems possible to implement Zip without
violating any patents or having to pay royalties to PKWare (eg.
InfoZip´s and 7Zip's implementations). Again, I´m not a lawyer but the
fact that OpenOffice and ODF use Zip seems to also confirm this. The
parts of Zip we recommend implementer implement are the open parts,
and we make it explicit that widget user agents are not required to
support any patented part of the Zip spec. So yes, Zip is proprietary
and that sucks; but at least the Zip spec is open and modular enough
for people to be able to avoid any patent pitholes (again, I'm not a
lawyer so everything in this paragraph is just speculation).

>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.
>

Yes, we have added a conceptual semantic layer for widgets to Zip.
However, and just to be clear, we have not changed or extended Zip in
any way whatsoever in doing so. We have only restricted some uses of
Zip which are mostly rarely used anyway (e.g., splitting archives,
discouraged the use of the broken password encryption, etc.).

>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.
>

Ok, that's a completely valid point and I totally agree that we should
not prescribe Zip. I have removed Zip as a normative reference in the
Requirements document. You will now find no mention of Zip in the
requirements document at all, not even in the examples.

Having said that, I have also changed the requirement on the
configuration format mandating the use of XML because that is also
being overly prescriptive. Following the line of reasoning you gave
above, if the market demands a future migration away from XML to, say,
JSON, then it is still in scope of the requirements to allow that.

> <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>
>

I guess it's a matter of proactive participation from the
MIME-supporting community. We have had a widget spec and requirements
under development for two years. The requirements have been published
6 times and you are the first person who has really stopped the
Working Group and said "hey! what about MIME???"... which admittedly
left us scratching our heads for quite a while. As we go forward, I
also think MIME needs consideration, but at the same time why don't we
push of PKWare to finally standardize Zip and integrate the advance
MIME stuff into Zip? Zip is more widely deployed then MIME and is
there really any reason why features can't be added to Zip to make it
do what (advanced) MIME provides?

> Or actually, why a Rec, not a Note, like other requirements documents?
>

I've been told this is a "cultural" decision... other groups have
taken requirements to Rec. We take our requirement gathering process
very seriously (that's not to say that groups who have produced Notes
don't!), and we want the same level of scrutiny to be applied to the
Requirements as any other specification on the Rec track. Also, we
want the normative aspects of the spec to be addressed by editors
because we believe the requirements to be representative of what
industry wants as a whole: As you may or may not know, Widgets are my
PhD research topic so I've personally spent at least a hundred hours
visiting different companies all over the world, talking to potential
implementers, discussing widgets with  developers, answering questions
on various blog posts, talking to end-users, answering questions on
this mailing list, etc. to gather these requirements. I feel strongly
that the Requirements represent what stakeholders want for V1, and
that is why I want to push for it to become a Rec: that way, the
normative parts protect the spec from being commandeered by any one
company or editor. The editor must only address the Requirements,
which represent the wants of the people:)

>> 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.
>

Ok, I've merged the text above with the definition given by the introduction.

>
> 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).
>

I don't think this note is really necessary. I want to keep the intro
as simple as possible without having the reader have to hyerlink
anywhere just yet (except for the landscape doc). The reader can
discover what the note says on their own.

> --
> 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."

Done, but I also kept the part about "not served with the appropriate
MIME type" and "whose MIME type is unspecified" to cover both cases.

> There are 3 outstanding changes:
> 1. Clarification that it's a widget user agent that's supposed to fulfill this.

Agreed. And now fixed.

> 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.
>

Agreed and I think the requirement now alludes to this without being
prescriptive.The packaging spec explicitly deals with this.

> 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.)
>

Ok, I don't know what to do here.. The problem is the word
"inappropriate". Is "unsupported" any better (i have changed the spec
to use "unsupported" after reading your rationale below)? In your
example, the MIME type is not the correct so processing would fail for
that resource (unless sniffing takes place on the SVG file or it
actually is an audio clip).

> 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.
>

yes, this has been an interop issue on the Web. Together with HTML5,
we want to patch holes where we can as long as they serve the Widgets
specifications.

>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.
>

I completely agree and rest assured that this was never the intention.

>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.
>

This will be in the spec itself. If it is ok, I will get you to review
the section on processing once we get to LC (but feel free to take a
look at what is there ATM).

> <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>

Understood. Like I said, we only need sniffing for when resources are
received from sources other than the web. When a WUA is getting a
widget from the web, it should follow standard MIME style processing.

>> (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.
>

Understood and agreed.

>> 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.
>

Text added.

>> 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).)
>

[This comment now refers to R6 in the latest editor's draft]

I guess that might be a side effect. The requirement has undergone
further revision and now reads:

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 (if any) 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, and 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"). To disable
access by widget instances to the underlying file system (if any) or
other resources which are not instances of the same widget or
resources contained in the widget resource used to create the current
set of widget instances.



>> 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 ;-)).
>

Limited discussion about this happened at the last f2f but no real
progress was made.

>>>> 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.
>

The WAI community also raised similar concerns. It is now a MUST.
However, I personally think that it is romantic to say that HTML on
its own can truly meet this requirement (though adding ARIA into the
mix seems to get us closer).

> 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.
>

Thank you for your kind words and for taking the time to provide us
with such detailed feedback. Your comments have been challenging for
me to answer and I hope that the changes that I have made to the spec
are to your satisfaction. To be sure, your comments have substantially
improved the quality of this specification and possibly the direction
the WG will take with this work.

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

Received on Tuesday, 9 September 2008 11:38:06 UTC