2009/9/17 Robin Berjon <[email protected]>: > On Sep 3, 2009, at 14:25 , Marcos Caceres wrote: >>> >>> Many specifications in the Web stack depend on a context being defined >>> that includes a current IRI. This is easily provided for documents >>> retrieved over HTTP, or from the local file system, but is currently >>> undefined for documents extracted from within a widget package. >> >> I don't like the above. Why are you starting this as an argument? > > It's not an argument, but I see how to change it.
Ok, I'll re-read it before we publish again. >>> This document was published by the Web Applications WG as a Last Call >>> Working Draft. This document is intended to become a W3C Recommendation. >>> If you wish to make comments regarding this document, please send them >>> to [email protected] (subscribe, archives). The Last Call period >>> ends 10 November 2009. All feedback is welcome. >> >> This LC period is too long. Make it 10th of October or mid October. This >> is to facilitate two LCs. > > We'll change that when we really do go to LC. As things stand, we might be > delayed a little more so I can address Jere's comments which require some > rearchitecting. Ok. >>> This specification defines the widget URI scheme that is used to address >>> resources inside a widget [WIDGETS]. >> >> change to "inside a widget package" > > That text is gone, but I've changed it elsewhere. Mmmkay. >>> There are many different efforts that have specified URI schemes to >>> access the content of Zip archives, or endeavour to do so. While these >> >> endeavour > endeavor > > Perhaps the day you pry my spellchecker from the unflinching grip of my cold, > dead fingers. The W3C mandates specs be in en-us [reference-needed] (it's part of a evil ploy the W3C has to enforce the US imperialist agenda through linguistic hegemony). >>> efforts have merit, and while W3C Widgets rely on Zip as a packaging >>> format, the use cases that this specification addresses are radically >>> different. >> >> "radically" is unnecessary. You make grand statements, but then don't >> back them. What is so radical about what we are doing? Don't tell me (I >> know how awesome we are!), put in the spec :) > > Hmmm, it seems to me that you don't know what "radically" means. It means "at > its root". We're doing something that is "at its roots" different. Something > that is "radically different" isn't necessarily "radical", in fact there is > little connection other than etymological. That being said I've changed it to > "substantially" to make it more K12 compliant :) > And there I thought radical meant "radical dude!" (Thanks A LOT, Ninja Turtles!) >>> The scheme defined in this specification could be used to implement >>> inter-widget communication, but that is outside the scope of this >>> current document. >> >> This is not proven. I would just say that cross-widget is out of scope >> and, may be future work, but not that it could be used for that. > > "Uniquely identifying widgets, or multiple instances of the same widget > package, as well as using that to enable inter-widget communication are > outside the scope of this document." > Nice. >>> 4. Requirements >> >> All this should be moved to the widgets requirements doc. > > I don't have a strong opinion but I'm not sure. The widgets requirements > document holds requirements for the whole family, but it stops before the > technical implications. I don't think that there's a requirement to have a > URI scheme when you go and create a widget platform, it just so happens that > the technical decisions we made lead to a place where we need one. > > But I'm happy to remove them if you want to past them in the WR — the shorter > the better! Yes, please. >>> Must not require widget developers to be aware of it for basic tasks >>> Using this scheme as the IRI of resources inside a widget must not force >>> widget developers to be aware of its existence for simple tasks such as >>> linking between widget resources, and would ideally not require such >>> knowledge for advanced tasks either. >> >> Yep... but I would qualify this as "the whole scheme" or "must not need >> to know about every component part of the scheme", as you need to at >> least know about the path component. > > I see what you mean — technically if you use the path bit then you "know > about the scheme", but that's not what I meant, really. People shouldn't have > to learn anything to use it for basic tasks (e.g. just do a path). I think > most developers don't think that they're using the ipath-noscheme followed by > ifragment when they link to "marcos.xhtml#nose". So I'm unsure how to change > this to reflect both sides. > Ok, leave it then (and I've asked before to not to make fun of my nose). >>> A careful review of existing schemes has found that none matches the >>> needs above. >> >> "existing schemes" needs references to all the ones we looked at. >> >> "careful review" > "review" and link it to the wiki or my presentation >> on the wiki. You might also link to the landscape doc, though I can't >> remember if I covered that in there or not. > > It's not in the landscape and I'd really rather not link to a wiki page. > Before starting I looked at the list of all IANA-registered schemes, plus > Wikipedia's list of commonly used non-registered schemes (it's not that much > work, most can be immediately discarded). I'd rather not list them all... > Ok, fair enough. This isn't a journal article and the people we are trying to convince already know the schemes we looked at. If I get around to it, I will add the URI schemes to the landscape and give rationale as to why we rejected them (based on the emails we sent to uri packaging scheme mailing list). > I'm dropping this sentence, if we had found something that worked we'd have > used it. > >>> As a widget is initialised the user agent may generate an identifier >> >> initialised > initialized. > > Perhaps the day a pack of transgenic hyenas will have licked clean the cold, > slushy part of my brain that handles spelling. Now you know the reason I'm in Africa. Expect hyenas as soon as I work out how to make them transgenic. >> "may" > will (statement of fact) > > Actually no, it's a may (in the spec it's even a MAY). There is no > requirement for it to do so, return widget:///foo/bar is correct. > > This will be clearer after I'm finished including a discussion of conformant > widget producers and consumers. Yes. >>> that will be used as the authority part of the widget absolute IRI. >> >> the widget > the widget's > > Yup. > >> I'm wondering if we should use the word "origin" here. > > No, at least not unless you want Thomas banging on your head (I don't). One > can define the origin to be derived from the authority, but it could just as > well be defined by the phase of the moon. Here we're just talking about URIs, > there's no origin. > Mkay, makes sense. Ok, I need help then in Widget Interface. I was kinda hoping WURI would define the origin. >>> As >>> of this specification that identifier has no semantics and must be >>> ignored while resolving the IRI reference to a representation. >> >> The above is confusing. Ignored by who? When? > > Widget consumers. When they're hungry. :( >>> If >>> present, the authority will be said to be opaque. >> >> "will be said to be" > is >> >> "opaque" needs to be defined. > > If present, the authority is said to be <dfn title='opaque > authority'>opaque</dfn>, which > means that it has a syntax as defined by [[!RFC3987]] but that it is devoid > of semantics. Why "is said to be", why not just "is"? >>> Future versions of >>> this specification may define more precise syntax and semantics for this >>> opaque authority. >>> 5.1 The widget URI scheme >>> >>> The URI scheme for widget URIs must be widget. >> >> must be widget > is a string that matches the production of >> <code>widget-URI</code>. >> >> You can't use "must" here, is just is. > > It's a must given valid widget URIs as a conformance class. Ok, well, if we have that as a class then sure: >> Also, that is not a valid URI. > > What is not? Can't remember:) >>> Its ABNF syntax [ABNF] is >>> therefore: >>> >>> widget-scheme = "widget" >> >> Please merge the above and the Syntax section below. It's all the same >> thing. > > Actually that's all going to change thanks to Jere's investigation. > Trusty Jere :) >>> Where the zip-rel-path non-terminal is defined in the Widgets 1.0: >>> Packaging and Configuration specification [WIDGETS] and the others >>> reference RFC 3987 [RFC3987]. >> >> Change: >> Widgets 1.0: Packaging and Configuration specification [WIDGETS] >> to just: >> [WIDGETS] specification. > > I'm not sure what you mean, the first one is more readable for non-academics > I think, and there are more than one widget specifications? > Ok, you is "da editor". >>> 5.3 Base IRI and Relative IRI Reference Resolution >>> >>> The base IRI for a resource contained in a widget must be constructed by >>> concatenating widget://, optionally the opaque authority, and the Zip >>> relative path to the resource. >> >> Base IRI needs a reference to something or needs to be defined. > > Yup. I'm assuming you defined it. >>> Resolution of relative IRI references is performed using the mechanism >>> appropriate for the language in the context of which the reference >>> appears, typically following chapter 5 of [URI] or possibly [HTML5]. >> >> I would put "(or, for instance, [HTML5])". >> >> We just don't want to risk a normative dependency. Another option is you >> make the last sentence a note. > > Or kill the reference, which is less confusing and still just as true. Works for me. >> >>> 5.4 Usage as Origin >>> >>> Mapping from a widget IRI to an origin is depends on the rules defined >>> for this purpose by the document type being referenced. >> >> "origin is depends" > "origin depends" > > Yup. > >> I don't understand the sentence above. > > It is just a reminder that what the origin is depends on the language of the > document which is at that location. Ah. Ok. So origin = whatever HTML, SVG, FOOBar says it is given a Widget URI structure? >>> Within an HTML 5 context [HTML5], the origin of a resource inside a >>> widget is defined by an extension to the HTML5 origin algorithm. >> >> Oh $...@$! seriously? Should this section be an Appendix or something? Are >> we really going to start screwing with HTML5? This section is currently >> normative. > > Well, how else? I'm certainly open to making it into an Appendix, but as > things stand I'm not sure we can work around this any other way. > Bah. I'm confused. I'm not getting it any more. > Currently step 4 says that "If url does not use a server-based naming > authority (...) then return a new globally unique identifier." This means > that two documents inside a given widget will not get the same origin. That > means that you can't share things like cookies and localStorage across > documents in a widget — a rather steep limitation. We also need to indicate > how serialisation happen, otherwise we're not getting the interop we came for. > Oh no! so does that mean that navigation is not allowed. What I mean is, start file = index.html, and index.html links to about.html? So about.html gets its own cookies and storage? That's bad. > It doesn't imply that we have a normative dependency on HTML5 (I think). > Here's a suggestion: we kill this section (other specs can figure out how to > handle origin), devolve the HTML5 content to an appendix called "Determining > the origin for widget resources that follow HTML5's origin-defining rules", > and just put this in. Yes it's normative, but it's only normative for > implementations of HTML5 (or that follow its origin rules). > What about SVG? Or FooBarML? This sounds like we are doing a HTML5 and acting as the authority on how to derive origins. This should be extensible so it just works with any DOM-based technology (yes, I live in a dream world). >> Again, "must" doesn't make sense to me in this context. Apply it to a >> user agent. > > Yup. > >>> 5.5 Mapping widget IRIs to Widget Resources >> >> Terminology is wrong in this heading: >> >> Change: >> Mapping widget IRIs to Widget Resources >> >> To: >> Mapping Widget IRIs to files within a widget package > > Yup. > >> Also, consistently switching between URI and IRI is giving me >> reader-sickness (a form of metaphorical motion sickness). I think we >> should just use IRI throughout and be done. > > It now uses URI throughout, stating that it really means IRI. I don't care if > it's clumsy, most English speakers I know can't even pronounce "IRI" anyway. > Ah! So your rationale is that English speakers are stupid? :P >>> The process of resolving a widget IRI to a resource within a given >>> widget is must operate as follows (or in a manner that guarantees the >>> same result): >> >> "is must" ? Please convert the above to something that applies to a >> product. Also, this spec lacks a conformance section that lists the >> products. > > Yup, incoming. Great. >>> 2. Let path be the path component of uri. Remove the leading U+002F >>> SOLIDUS ("/") from path. >> >> You don't need 2, the rule for finding a file within a widget package >> already does this for you. > > Okay, cool. > >>> 3. Run the algorithm defined in Rule for finding a file within a widget >>> package using path as its parameter. What it returns is the file entry >>> being sought. >> >> It return a "file". A file entry is a different thing (sorry about the >> confusion). > > Yup. > >> Or may return an error, which needs to be handled. > > So the problem here is that we're not in the business of creating a protocol. > I think we should pass the buck: if it returns an error, it's up to the > context in which this request is being made to handle it. It might display an > error or it might fallback, that's not up to us. > Right. >>> Note that neither the query nor the fragment parts of the widget IRI are >>> used in the resolution process. They must nevertheless be kept as part >>> of the IRI and processed according the rules defined by the content type >>> being referenced. >> >> Ok, we have a problem here: the P&C's rule for finding a file within a >> widget package can't cope with fragments and queries, so in 3, make is >> super clear that the UA needs to chop off the query and fragment parts. >> That's kinda clear already, but, it does not hurt to be a little bit >> more clear. > > Right, I've added that it excludes these. > > Thanks man! Oh no! thank you! -- Marcos Caceres http://datadriven.com.au
