Re: CSS Query API: selectorQuery(...)
On Jul 19, 2007, at 19:07, Bjoern Hoehrmann wrote: The WebAPI Working Group is considering to conduct a poll to finally put the method naming issue in the CSS Query API specification to rest; Charles asked us to propose alternatives to selectElement/ selectAllEle- ments. To this end, I would like to propose using two [1] of selectorQuery(...) / .selectorQueryAll(...) / .selectorQueryOne(...) +1 from me. -- Robin Berjon - http://berjon.com/ Rated R for Robin
Re: New staff contact - Doug Schepers
On Jul 06, 2007, at 14:57, Chris Lilley wrote: Doug Schepers, who you all know, is now the WebAPI staff contact. Excellent news! Congrats Doug, and best of luck :-) -- Robin Berjon - http://berjon.com/ Formal description of XML Schema? So it's a picture of a turd in a bow tie? -- Chris Prather
Re: XHR: sending documents
On Feb 22, 2007, at 09:50, Bjoern Hoehrmann wrote: I would suggest to remove (the XML declaration) since xmlEncoding is not the XML declaration, and turning it into e.g. (as derived from the XML declaration) is unnecessarily long. The last sentence is not really appropriate for XML documents, first the requirement is essentially im- plied by the requirement that the result must be namespace well- formed, and there are other cases where the XML declaration is required, e.g. if the Document is an XML 1.1 document. I would suggest to remove this, or turn it into a non-normative note clearly indicating that this is just one of many requirements. +1 to removing it. I think there needs to be a node clearly stating that even if you try to send a HTMLDocument, it will be serialized as if it were XML. Agreed. Does the XHTML namespace get added automagically? It might also be worth to note that on sending, the implementation takes a snapshot of the document and subsequent modifications of the Document during async upload are not reflected in the result. Yes, that will certainly alleviate some confusion from users who think XML == DB. The main flaw here however is that it may not be possible to meet the requirement to create a ns well-formed document, for example, if it contains a processing instruction whose data includes ?; it is not possible to represent such a Document as an XML document. The draft has to address this case. I can't think of anything useful that the UA can do on its own there, I'd suggest throwing an exception (DOMError or some such). -- Robin Berjon - http://berjon.com/ RDF is like violence: if it doesn't work, use more!
Re: Selectors API naming
On Jan 25, 2007, at 21:18, Ian Hickson wrote: I think the mailing list is fine. However, I don't see that the current decision is any closer to the community's consensus opinion than Anne's own compromise proposal, and therefore I don't understand why the working group would override the editor on this. Precisely. There is no consensus. That's easy to see. There wasn't going to be a consensus. Given that, it is the group's job to make an executive decision, and the editor really has no say in this, except in that s/he is part of the group. It is excessively clear to me that the WG went to great lengths to discuss this topic entirely openly with the public. This has been on the public table for over one month, with dozens of messages exchanged, and participation from both WG members and the community at large. In many cases this process has provided quality output, but on occasion, as everyone knows, it fails. And when it does, a different process is needed. You can cry out your shallow populism by talking about things taking place behind closed doors and in full opacity, it nevertheless remains that the WG did the right thing. It raises a bad precedent. If the editor is to be overriden on every little thing -- especially in cases like this, where we're moving from a set of names that a minority liked to another set of names that a different minority likes -- then we should change the editor, as it indicates that the editor is not being trusted by the working group. Quite frankly, that is total bollocks. The WebAPI has always been a strongly editor-driven. The process is normally this: an editor comes up with a draft, if there's consensus it's good, and if there isn't consensus the WG needs to make a decision (something which is usually done by asking this list for input). The size of the thing doesn't matter — otherwise there would need to be consensus on how important it is, which is endless — it's a simple matter of consensus. It certainly is not a matter of trusting the editor, no one can get consensus on everything, so whoever takes on the charge of being editor knows they'll be overruled on occasion. But of course if you actually participated in the WG as your membership allows you to instead of wasting everyone's time with uninspired drive-by comments on process, you'd know that already. (I don't think we should change the editor -- I think Anne is doing a fine job. I think the working group should let him do his job without micromanaging the names.) There is no micromanagement. No consensus means group decision, end of story. I don't think the WG needs you micromanaging its process thank you very much. -- Robin Berjon - http://berjon.com/ My whole life is waiting for the questions to which I have prepared answers. -- Tom Stoppard
Re: Selectors API naming
On Jan 25, 2007, at 21:51, Robert Sayre wrote: I encourage you to read the WG charter. http://www.w3.org/2006/webapi/admin/charter I think Jon knows the charter :) Looking over the charter, I see the proceedings of the WG are Member-Only (bad) That is the default. Note that in January last year (i.e. at the very beginning of the group) the WG decided to perform its work in public, which they are doing. If the WG doesn't provide public minutes It used to, but it is a lot of work (since they need to be cleaned up) and people in the community rarely answer, which seems to indicate that they never read them. , and doesn't otherwise respond to public comments from WG members and the general public, This WG responds all the time, I don't know why you're saying that. I think it should change its charter to be entirely Member Confidential. I wouldn't want that, but it seems like it would be more accurate. This comes from completely nowhere. -- Robin Berjon - http://berjon.com/ I write plays because dialogue is the most respectable way of contradicting myself. -- Tom Stoppard
Re: Selectors API naming
On Jan 26, 2007, at 19:05, Robert Sayre wrote: Well, I saw several comments from significant implementors that indicated they were unhappy with getElementsListBySelector. I don't think the WG needs to provide detailed minutes, but a list of people present at the meeting and a coherent rationale would do the trick. I'm not saying that transparency can't always be improved but major implementers are participants in the working group (at the very least Opera, Apple, Microsoft, and Mozilla, not to mention folks from major mobile companies, folks that reuse browser components, and others) so presumably if the WG reached consensus they either took part in it or decided not to take part (which counts as accepting the consensus of those who do). I'm not longer on the WG so I don't know how the decision was made, but I strongly suspect that people agreed that no amount of discussion was going to get everyone to agree so they probably went for the decision that made the smallest number of people unhappy. For a naming discussion in which there is no consensus, it's unlikely that you'll get any other kind of output I'm afraid. PS: the quote at the bottom of this email was chosen at random I swear :) It's just the way of the SigMonster. -- Robin Berjon - http://berjon.com/ Interestingly enough - rendering dozens of plasticine bunnies floating in a giant vacuum cleaner complete with fake finger prints is actually easier than doing websites. Good job Microsoft and Netscape! May you rot in hell. IN HELL! -- Simon Wistow, london.pm
Selector API names - strawman
Hi, while I hate naming discussions just as much as the next guy, the last proposal out is so deeply inept that I see no other option than to reopen this. Here is a proposal that is intended to satisfy both the brevity nazis, and those who like meaningful method names. I don't really like them myself, but I can live with them. - Document.css() - Document.cssAll() - Element.css() - Element.cssAll() Same length, but with meaning. -- Robin Berjon - http://berjon.com/ Never doubt that a small group of thoughtful, committed people can change the world; indeed, it's the only thing that ever has. -- Margaret Mead
Re: Selectors API updates
On Jan 09, 2007, at 23:08, Anne van Kesteren wrote: I updated the Selectors API specification today and added equivalent methods for element nodes. It didn't make much sense to me to postpone this. I resolved the naming debate by going for: * Document.get() * Document.getAll() * Element.get() * Element.getAll() These names are short, don't clash with autocomplete and provide a superset of the functionality given by the other get* methods. Sorry, I don't wish to reopen the naming debate, but these really don't strike me as the ones closest to consensus (aside from being dreadful picks). I think there are a bunch of names that people don't like but can live with, these are just pure nonsense. I certainly know that while I would have dropped the ball on any number of bad options, if these stay in the draft I will request formal objection from my AC Rep. -- Robin Berjon - http://berjon.com/ In which level of metalanguage are you now speaking?
Re: heads-up on use of unnamespaced event types in XBL2
On Jan 08, 2007, at 14:28, Jon Ferraiolo wrote: If XBL2 markup is put into a separate XBL namespace, then it makes sense that XBL2's events are also in a separate XBL namespace (same namespace URI). Also, if you put the events in the XBL namespace, you should remove the xbl- prefix on the event names. The WebAPI WG's consensus (obtained with blood and tears) on this topic has so far been that while namespaces are required so that application components can define their own namespaces, namespace proliferation isn't desirable. As a result, the WebAPI WG has declared itself competent to assign names in the null namespace, if only for itself and other W3C WGs. I don't really care either way, but it's nice when policies don't change, and when consensual decisions are not revisited, especially those that were painful to all involved :) -- Robin Berjon - http://berjon.com/ We need to create a hybrid country which has the best of all worlds! Italian food, Italian people, Italian landmarks, Italian sport, Italian conversations, Italian politics, Italian women, and English scones! -- Sean B. Palmer
Re: Selectors API naming
On Dec 20, 2006, at 14:51, Anne van Kesteren wrote: No, the Selectors specification is separate from CSS. That belief only exists within the small ivory tower known as The CSS Working Group. To those of us who actually use the stuff for work, that distinction is a totally moot political statement of interest only standards people with too much time on their hands: selectors are, and will always be, CSS. That's why if you want to address the needs of us folks as opposed to your own politico-religious quibbling, calling it something along the lines of matchCSS makes most sense. -- Robin Berjon - http://berjon.com/ If Beethoven had been killed in a plane crash at twenty-two, the history of music would have been very different. As would the history of aviation, of course. -- Tom Stoppard
Re: Selectors API naming
On Dec 20, 2006, at 23:02, Ian Hickson wrote: This thread is going nowhere. I propose that we let the document's editor take into account all the input and then have the editor make a decision that addresses everyone's concerns as much as possible. There's no point us arguing over names, we'd only end up with a spec full of compromises and smelling of design-by-committee. Beats reeking of design by theology. -- Robin Berjon - http://berjon.com/ Computer games don't affect kids, I mean if pac man affected us as kids, we'd all sit around in a darkened room munching pills and listening to repetitive music.
Re: PAG for REX?
On Oct 30, 2006, at 13:28, Arthur Barstow wrote: Does this mean a Patent Advisory Group (PAG) will be formed (per [W3C-PP])? In theory, yes. If yes, when will the PAG be formed? We don't know, that is the Director's discretion. P.S. My apologies if this is the wrong mail list for my query but please do advise me of the appropriate list. This list is fine, but some aspects of PAG-related business are naturally confidential so I recommend that you get in touch with the Chair directly. -- Robin Berjon - http://berjon.com/ --- - Will we have donkeys? - All you can eat! -- She-Bender Calculon, Futurama
Re: XMLHttpRequest: Why list HTTP method names
On Oct 17, 2006, at 15:23, Mark Baker wrote: Common practice with HTTP is what declares what methods are in use at any given time. If common practice were enough, the spec in its entirety would be useless. There's lots of common XHR practice. Besides, the Web's a big place. A lot of people use, say, PROPFIND many times a day (often without knowing it), others have never heard of it. I don't think I'm making any manner of radical statement if I say that you don't build interoperability on hand-waving towards common practice, implementers' common sense, or other such mythical animals. -- Robin Berjon - http://berjon.com/ --- So, if this show teach you anything, it should teach you how to respek everyone: animals, children, bitches, spazmos, mingers, lezzers, fatty boombahs, and even gaylords. So, to all you lot watching this, but mainly to the normal people: Respek! West side! -- Ali G.
Re: XMLHttpRequest: Why list HTTP method names
On Oct 14, 2006, at 15:20, Anne van Kesteren wrote: On Fri, 13 Oct 2006 14:18:56 +0200, Robin Berjon [EMAIL PROTECTED] wrote: And you guarantee interoperability how? It's not the job of the XMLHttpRequest specification to guarantee interoperability on HTTP level features, imho. Anyway, as indicated, this is likely to be tested in the testsuite. If you can't guarantee that at least a core set of methods will work, the API is simply useless. -- Robin Berjon - http://berjon.com/ --- I have yet to see any problem, however complicated, which, when you looked at it in the right way, did not become still more complicated. -- Paul Anderson
Re: XMLHttpRequest: Why list HTTP method names
On Oct 13, 2006, at 01:55, Anne van Kesteren wrote: I actually agree with Mark (earlier on) and Subbu. It's not the job of the XMLHttpRequest specification to decide which methods have to be supported. Whatever the implementation cost actually is. And you guarantee interoperability how? -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: Liaison from JSR-287/280
On Oct 11, 2006, at 00:09, Anne van Kesteren wrote: On Tue, 10 Oct 2006 17:22:25 +0200, nandini [EMAIL PROTECTED] wrote: Do you have a timeframe for when these additions will be made and when the specifications will be published? Regarding a draft specifying progress events, I'm not sure either. The plan was to have something by the end of this year I believe. As usual our ability to make progress (no pun intended) depends highly on our resources. Currently we have more specifications to deliver than active members. Given the overlap between W3C and JCP members, I can only expect that the JSR-287 and 280 EGs have several participants who could lend a hand. It would be most useful. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: [comment-rex] Mutation events
Hi Karl, On Jul 03, 2006, at 08:32, [EMAIL PROTECTED] wrote: The specification is restricted to mutation events but doesn't remind the reader of what is a mutation events. It will be good to have a reminder of the definition of a mutation event. Good idea, I've added a quick reminder. Thanks! -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: [comment-rex] recursivity of a rex element
Hi Karl, On Jul 03, 2006, at 08:32, [EMAIL PROTECTED] wrote: Can a rex element be applied on another rex element or on itself. If not, what's happening? A REX message can be applied to any XML document. I'm not entirely clear on how a message could be applied to itself (in the sense of the same same instance). Do you have a specific recommendation for change in the specification? -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: comments on Selectors API WD
On Sep 30, 2006, at 04:21, Daniel Glazman wrote: Robin Berjon wrote: I don't think we need to cram as many features as possible into v1. Defining the exact semantics of scoped CSS selectors can be a little tricky, and it clearly is the job of the CSS WG to do so. The WG thinks Tricky. Ah. When it comes to defining how matchSingle() and matchAll() work, I fail to see how, sorry. You don't have to worry about specificity, cascade or precedence because Selectors API do not deal with it! We have to worry about defining how scoped selectors work. *That* is the tricky part. It's not a question of being technically difficult, it's a question of overstepping our boundaries. A stylesheet applies to a subtree, that subtree being the whole document. A scoped stylesheet applies to a deeper subtree, that's all. No it's not all, as you note immediately after this paragraph there is at least one issue. The one and only issue is the :root matching, and it makes perfect sense here to say it matches the root of the subtree because there is no other root element in this context ! The other option, ie match the root of the document, is pure non-sense... In the scope, that element is just not visible. And here you prove my point. I come to the exact opposite conclusion from you. I think that having :root match the root of the subtree and not that of the entire tree is pure nonsense. Again, it's not up to us to decide. If we do get to make that kind of decision, the first thing I'll ask for is to rename the Selectors draft to something sensible that reflects its content :-D I thought your WG was more disruptive than that :-) Seriously, we're really, really not! Boring and conservative, that's us! More seriously, I really think this WD does not push far enough. The cost is little. Your WG and the CSS WG could probably solve this quickly. If the cost is small then it'll be just as small in v2. 4. I really hate having two different methods for matchSingle and matchAll, and I'd prefer a single method with a boolean indicating if only the first result should be retrieved or all. I think that's largely a matter of taste, isn't it? No. That's a matter of consistency. Having similar methods both performing a search, the result of the first one being a subset of the second one, reply similar constructs is a matter of consistency. I don't see the consistency argument here, and I really do dislike methods that pile up long lists of ordered boolean arguments. It always starts with one, too. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: comments on Selectors API WD
Hi Daniel, just expanding on some of Anne's arguments. On Sep 29, 2006, at 09:50, Daniel Glazman wrote: 1. I think the title of the document is badly chosen. The WG went through that discussion already. Unless new arguments can be provided than those which have already been beaten to death, I would really, *really* prefer we didn't have yet another discussion on the name of something to do with Selectors. Please. 2. I think it's an error to restrict this new API to the document level, in particular if we have scoped stylesheets in the near future. I recommend extending the API to all nodes. I don't think we need to cram as many features as possible into v1. Defining the exact semantics of scoped CSS selectors can be a little tricky, and it clearly is the job of the CSS WG to do so. The WG thinks that it's simpler and safer to restrict ourselves to Document at first, and extend to Element (or Node) later, rather than do the latter now and find out later that it introduces issues with what the CSS WG intends to do in the area. 4. I really hate having two different methods for matchSingle and matchAll, and I'd prefer a single method with a boolean indicating if only the first result should be retrieved or all. I think that's largely a matter of taste, isn't it? 5. Disruptive Innovations SARL becoming a W3C member on the 1st of October, we are ready to help on this specification. That's excellent news! -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: Comments on File Upload
Hi Mark, thanks a lot for your review. On Sep 21, 2006, at 15:18, Mark Baker wrote: Editorial; - sec 1, This interface should be This specification - sec 3, I'd suggest s/apparition/display/ Applied. Substantive; - sec 3, regarding On devices that have no file system, the user-agent MAY still open a dialogue for data acquisition, for instance an interface to a built-in camera, my concern is that the file dialogue should be considered generic, not specific to any form of data, so I don't want to give the impression that the device can choose the data without user involvement. So I'd suggest for instance, a dialog which identifies a built-in camera and a microphone. Agreed, I've made a change similar to your suggestion. - sec 4, not that I care that much, but do we really need this interface? Would an array not suffice? It can't do remove, of course, but is that such a big deal? I'm not at all a big fan of all the FooList interfaces that show up here and there in W3C APIs, but I'm unsure as to how to handle this in a language-independent manner. What it maps to is binding-specific mind you, so in ES it would certainly have the behaviour of an array. I think that once we make progress on the Bindings for ES specification (Jonas?) we'll see more clearly on this issue. - sec 4, I don't think SHOULD is appropriate there, for selecting multiple files - MAY should be fine. Plus I think it's best specified in sec 3. I've moved it to section 3 as I agree that it does make more sense there. However I do think that the SHOULD is justified here. If the platform on which the UA is running has a way of selecting multiple files, then it definitely must do it — the single file selection of UAs since the introduction of input type=file has been a genuine pain. The only reason it is a SHOULD and not a MUST is due to hypothetical platforms that may not have a FS (as mentioned two points above). I have half a mind to forget about that and make it a MUST. What do you think? - sec 5, filesize - do we know the use cases for this? Yes, a non-negligible number of sites request that users not upload files bigger than X. This does not provide for server security, but it gives the page a chance to tell the user that a file is too big before it is submitted. I don't think the definition provided would be useful for much beyond scenarious using some files in a file system. Well, that is the primary use case :) What if a camera had an 8MB buffer, but image sizes could be up to that size? Or similarly, what about an audio stream? And is this meant to be a string? No, it's definitely not meant to be a string, good catch. - sec 5, mediatype - do both and null values indicate that the agent doesn't know the media type? And are we expecting this to be just be the foo/bar value, or would parameters also be included? Need some references too. Good questions, I've added an editorial note to that effect. Thanks! -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: [File Upload] Security problems with File Upload
Hi Ian, On Sep 22, 2006, at 17:15, Ian Hickson wrote: It seems like it would make it possible, through an attack like the famous fast clicking game, to cause a user to select a file (probably at random, but from the user's home directory, so likely a confidential file). There are well-known workarounds for this, notably delayed activation of the dialogue. This could be noted in the specification. I would feel much more comfortable if the FileList API was provided merely as an extension to the HTMLInputElement interface, thus requiring authors to use an input type=file control, and requiring users to click the Browse button before the dialog would appear. The problem with this solution is that it then requires that the environment supports input type=file, which isn't always the case. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: [comment-rex] Processing and well-formedness
Hi Karl, thanks for your review! On Jul 03, 2006, at 06:32, [EMAIL PROTECTED] wrote: About http://www.w3.org/TR/2006/WD-rex-20060202/#processing When the user agent ignores the remainder of the rex messages, should the user agent inform the user that it has stopped processing. Unless you're running a debug environment or have comparable requirements, definitely not. REX is designed to be resilient over unreliable networks (since it can be used for events broadcasting), and it doesn't make much sense to alert the user to every network issue. Would you like to see a specific change concerning this question, or is this answer sufficient? -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: [comment-rex] Editorial
Hi Karl, On Jul 03, 2006, at 06:32, [EMAIL PROTECTED] wrote: About http://www.w3.org/TR/2006/WD-rex-20060202/#specabstract In the first sentence of the abstract change This specification defines an XML [XML] grammar intended for representing events as they are defined in DOM 3 Events [DOM3EV], primarily but not exclusively for purposes of transmission. by Remote Events for XML (REX) 1.0 is an XML [XML] grammar for representing events as they are defined in DOM 3 Events [DOM3EV], primarily but not exclusively for purposes of transmission. Thanks, applied. Maybe there is a typo in a DOM representation by sending it DOM Events I don't think so, what are you thinking of? -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: [comment-rex] result of an event
Hi Karl, On Jul 03, 2006, at 06:32, [EMAIL PROTECTED] wrote: About http://www.w3.org/TR/2006/WD-rex-20060202/#elem-event What's happening when an event replaces a chunk of XML in a document and for example creates a new id in the document which already exists elsewhere. Specifically when a further event applies on this specific id value. Ex: 1. document with id=foo 2. event1 creates another id=foo somewhere 3. event2 applies on id=foo (but there are now two in the document) In order to avoid redefining the error handling defined in other specifications, REX defers to the underlying DOM that is being manipulated for such issues, as described in section 6.1. If the underlying DOM has undefined behaviour for such a case, it's not our job to fix it. Hoping that this addresses your concern, -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: XmlHttpRequest IDL non normative
On Jul 24, 2006, at 16:24, José Manuel Cantera Fonseca wrote: It really sounds strange to me. To specify something in IDL that is not OMG-IDL-conformant but you are going to use the bindings of OMG- IDL. I'm not sure what you mean by us[ing] the bindings of OMG-IDL, but I don't think we are. The IDL in the draft is there because it's intuitive to people who are used to the DOM specifications and the such. We're not trying to conform to OMG IDL simply because it's not powerful enough to capture what we need to express. If you are not going to use the sintax and semantics of OMG-IDL it could be better not specifying the object in IDL. You could do it directly in EcmaScript. I'm not sure Ecmascript would be a good option here, but I don't have a strong opinion. The best option would be to document a Web API IDL but that's quite a lot of work. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: Optional method arguments in the DOM
On Jun 29, 2006, at 22:12, Joseph Kesselman wrote: We didn't do optional arguments for the same reasons we didn't do some other things in the DOM: they aren't supported in enough languages that they really belong in the core/portable/standardized specification. Given that they can be mapped naturally onto Javascript and Java (and a bunch of others), and given that language-specific bindings can override that to make them required if it's really needed, I don't see why we shouldn't have them. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: ACTION-87: Selectors API
On May 30, 2006, at 15:55, Ian Hickson wrote: On Tue, 30 May 2006, Jonas Sicking wrote: What we could maybe do though is to return a real ECMAScript array. I actually like this idea a lot since that'll integrate much better with scripts than a StaticNodeList would. That makes a lot of sense. I support this. Heck yeah. Jonas: I think that would constitute a very good thing to put in the Bindings 4 DOM document. Of course, it's mean of me to suggest this means you have a new action item, but you can only blame yourself for having good ideas. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Agenda requests?
Hi y'all, does anyone have any specific agenda requests for the call later? -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: REX and XUP
On May 22, 2006, at 10:39, Paul Libbrecht wrote: May I raise the fear that both REX and XUP might get affected by XQuery Update ? I've just heard about it: http://www.w3.org/TR/xqupdate/ To me XUpdate tasted much tinier but with the power of XQuery nowadays... No, they are in completely different spaces, thankfully. XQU is more like updating a DB than updating a document. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: typo in REX requirements?
Hi Ruud, On Feb 10, 2006, at 01:43, Ruud Steltenpool wrote: in http://www.w3.org/TR/2006/NOTE-rex-reqs-20060202/ : . This ensure the integrity Thanks, this has been fixed. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: REX and XUP
Hi, On Feb 12, 2006, at 23:05, Jin Yu wrote: I just went through the REX working draft. It's very interesting and I believe this is essential for a richer and more interactive web. In the draft, I did not find any reference to XUP, which is very similar in nature; so I just want to bring it up to share with you. That's my fault. When I started looking at similar solutions existing elsewhere to see if the need had already been addressed, I looked in many places... but not W3C! XUP looks like a very nice start for a specification, it's a shame that while W3C accepted your Member Submission (back then called Notes) but that it was not put on the Recommendation track by a WG. Do you know why that was the case? In XUP, UI updates are the same as mutation events in REX's terminology. Basically, UI updates are just remote DOM manipulations (add, remove, update elements, etc.) of a UI model, which is a DOM instance of an XML UI language. In XUP, the UI updates are bi-directional. That is, the user agent sends UI updates to server, containing end user's direct manipulations as well as the UI changes made by scripts; and the server sends UI updates to the user agent, containing server-side application's changes to the UI model. This can be done in REX as well: there is no assumption that the communication is only unidirectional (although that mode is supported since it's a strong requirement). If there are intended request/ response semantics, they are expected to be at the protocol binding layer (so for instance if someone made a SOAP binding for REX, I would expect it to have some strong similarities with XUP). In addition, XUP supports multiple event models. It supports DOM-style capture / bubbling events, as well as Java Swing-style delegation- based events. For REX we decided to only support DOM Events as that is simpler and is more likely to integrate well with the event infrastructure used by many W3C UI technologies. Can you think of specific things that could not be done by using only this model? The major difference with REX is that XUP is a protocol, and it has a SOAP binding. The SOAP binding is not critical; in fact XUP could be used with other transport mechanisms as well. Right, REX is meant to be a pluggable piece of technology, to be reused in a variety of situations. Proposals have already been made to integrate it with streaming protocols, with BEEP, and with HTTP. No one has yet suggested providing a SOAP binding for it, but I would expect that to be straightforward enough. The precise reason why it isn't a protocol is because when we started we already knew that people wanted to use it both in broadcasting and in request/response scenarios. I hope XUP will be a useful reference material for this WG. It definitely is, thank you very much. In fact, we intend to steal some of its features at some point :) Of notable interest are session initiation (for protocol bindings) and listener manipulation. Thanks a lot! -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: ISSUE-75: Is method case-sensitive?
On Apr 23, 2006, at 11:51, Anne van Kesteren wrote: On Sun, 23 Apr 2006 05:18:24 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: That being said, whether all methods are uppercased or only the methods that get significant use, is not really a major issue. But let's not just casually increase spec complexity without doing our due diligence. We also haven't decided yet, ISSUE-74, whether or not to allow arbitrary method names. Internet Explorer 7, for one, doesn't support it as has been pointed out earlier. Is there a known reason for this? IE7 is not yet legacy, though I guess it has the ability to be LOA (Legacy On Arrival) which is a potential pain indeed. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: XMLHttpRequest readystatechange events
Hi Boris, On Apr 23, 2006, at 20:51, Boris Zbarsky wrote: At the moment, Gecko allows adding a single onreadystatechange listener that's notified of changes in readyState. We would like to add the ability to add such listeners via addEventListener; the event name would be readystatechange. So basically this would amount to supporting EventTarget on XHR, right? This has been discussed several times by the WG, and while we like the idea it's pretty much a v2 thing. Does this seem acceptable? If not, are there counter-proposals? Same answer as in the previous mail :) -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: XMLHttpRequest progress events
On Apr 23, 2006, at 23:26, Bjoern Hoehrmann wrote: SVG could http://www.w3.org/TR/DOM-Level-3-LS/load-save.html#LS- LSParser consider compatible with existing specifications also... Weren't you at the meeting where D3LS was deemed unofficially obsolete? ;) More seriously, I think you meant LSProgressEvent no? It has various issues, some of which being that it is defined in a way that assumes XML by discussing external entities, and is also defined in terms of parsing and not data acquisition. None of this makes much sense for arbitrary content. It would also have to be subsetted to not bring in LSInput, by which point we would be left with two fields, still tied to XML, and one of which, just to make things better, is poorly named. If compatibility with D3LS was a goal, we'd have to also drop large parts of XHR, and also reuse LSLoadEvent. At the f2f we did actually consider asking the community at large if they would object to simply rescinding that document, not necessarily because it's technically bad (though it does have its shortcomings) but simply because it has been overtaken by events. We decided to not do so because it seemed simpler to not attract attention to it. I note that an event name 'progress' in no namespace and no prefix is likely to clash with W3C's work on XHR, so I don't think it would be a good idea to give no advise on this. That's why I was asking Boris who he was asking and what he was asking for. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: ISSUE-75: Is method case-sensitive?
On Apr 23, 2006, at 02:00, Maciej Stachowiak wrote: On Apr 21, 2006, at 12:53 PM, Mark Nottingham wrote: How about 1) always uppercase anything matching (case-insensitive) GET POST PUT DELETE 2) everything else gets sent as-is This sounds viable but also harder to implement than always uppercasing and the benefits seem purely hypothetical. It is a little bit more work but it doesn't really sound much harder to implement to me. The benefits are, I believe, three: it keeps existing content that works today working, it allows for other methods to use lowercase methods, and, last but not least, it appears to be the position most likely to garner consensus. BTW I don't understand why people think losing the ability to send lowercase or mixed-cased methods (something that is highly unlikely to have interesting use cases) amounts to the sin of profiling http, but no one objected to restricting what headers may be sent, even though that profiles http just as much, and in a way that has more practical consequences. Unless I've missed something, we have only forbidden headers that we know of, and that we know to be problematic, most notably for security reasons (there has been push-back on restricting for other reasons, e.g. the encoding case). If a new HTTP extension comes about, the people designing it will generally not have to care about the existence and behaviour of XHR. This is fine since it promotes independence of design. If on the other hand we decide to prohibit lowercase methods, specifiers of such extensions will be required to have arcane knowledge of XHR, of the kind only possessed by people who will have read the spec paying great attention to detail. It's not good for independence, it's not good for least surprise, and while small it's still another addition to the many things that can trip people writing specifications or creating technology. If possible, it should thus be avoided. Let's face it, XMLHttpRequest only offers access to a subset of HTTP protocol features, this is not avoidable, now let's pick that subset based on pragmatic considerations, not theoretical purity. I wholeheartedly agree, but the problem is that one's theoretical purity is often someone else's pragmatism. We could try to figure out who's right, but it would likely get quite theoretical, and more importantly rather long :) What would folks think of closing the issue with Mark's proposal? -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: DOM3EV: Editorial comments
On Apr 20, 2006, at 01:57, Cameron McCormack wrote: If an implementation of the interface does not have the handleEvent method, then I don't think it's an implementation of that interface. If on* attributes and ES Function objects are mapped to EventListener objects behind the scenes (even just conceptually) then it would be OK just to refer to the EventListener interface here. It's the other way around in fact, the EventListener is mapped to Function (and currently, not give a handleEvent member, though I think it would be better to have one pointing back to the object itself, for compatibility with at least ASV and possibly other SVG UAs). -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: DOM3EV: Specifying inappropriate modifiers to MouseEvent.initMouseEventNS
On Apr 20, 2006, at 02:20, Cameron McCormack wrote: leaning towards B just because it's more easily implemented, and I can't think of a valid reason for caring about whether Tab was specified as a modifier or not, especially if there is no way to get the list of all modifiers in effect. I could imagine tiny implementations that would want to avoid storing strings for modifier keys, and would favour just storing (1) as a bitfield, but DOM 3 keyboard events are already pretty string heavy. I think B is the only option here, no one is ever going to write an application that actually has the knowledge to differentiate between the 1 and 2. And if someone did it, I'm sure the following week some weirdo would come up with a keyboard on which Tab can be used as a modifier too. I don't think that storing as a bit-field is all that important in Tiny, it wouldn't optimise much. Besides, the Tiny subset of keyboard events don't have getModifierState() ATM. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: DOM3EV: Which events are fired for name mutations
On Apr 20, 2006, at 02:31, Cameron McCormack wrote: Two options: 1. never send the individual mutation events (and hope that the implementation does support the MutationNameEvents feature), or 2. send the individual mutation events only if renameNode falls back to node replacement. I'm not sure that I have a preference, but (2) is easier to implement. As an author I would much prefer (1), as it means consistency. Option 2 is also a bunch of events, remove element, add element, set attributes (the two latter stages being having invertible orders, which has different effects on bubbling, etc.). -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: ISSUE-75: Is method case-sensitive?
On Apr 20, 2006, at 23:42, Mark Baker wrote: I'm not aware of any HTTP extension methods which use a lower case character, so why not make method case-insensitive, but prescribe that it be converted to upper case in the HTTP message? A few years back I implemented the server-side of an HTTP based protocol that was heavy on camel-case methods, and I know I just tested for string equality. I don't know what they used for requests, but I believe the app is still running, and I wouldn't be surprised if they tried to talk to it through XHR. Sure it's an easy fix in that case, I don't know how widespread that sort of thing may be, and I don't necessarily believe it was the nicest design, but I would certainly like to avoid such munging if at all possible. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: ISSUE-75: Is method case-sensitive?
On Apr 21, 2006, at 00:18, Mark Nottingham wrote: Make it a SHOULD and twiddle your CR exit criteria to take it into account; in the long term, implementations will sort themselves out. My thoughts exactly. The real danger here is that the WG will be tempted to use the API to profile other parts of HTTP for convenience, or based on current implementations, as well. Please, don't. Precisely. Anne raised concerns about exiting CR, but if we start profiling HTTP we'll never get out of LC. I can already hear the hordes clamouring when you pry RFC 2616 from the impervious grasp of my cold, dead fingers. I'd also note that Apache preserves the casing of HTTP method all the way through mod_cgi. That's the case with all the server-side implementations that I'm aware of. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: DOM3EV: Editorial comments
Hi Cam, thanks a lot for these comments. On Apr 16, 2006, at 15:19, Cameron McCormack wrote: In 1.5 it says All events defined in this specification are in no namespace. and in 1.5.2 All event types are in no namespace and this specification refers to them by their local name only. Is it the events or the event types that are in namespaces? The events, the types are the local names. Used to specify the time at which the event was created in milliseconds relative to 1970-01-01T00:00:00Z. Due to the fact that some systems may not provide this information the value of timeStamp may be not available for all events. Does 1970-01-01T00:00:00Z use a common enough time format to warrant not mentioning how it should be parsed (by readers)? Are leap seconds included in this offset? Z always has leap seconds, no? The DOMFocusIn and DOMFocusOut event types are listed as being within the XML Events namespace, but they should be in no namespace. Yes, that's been fixed in the internal draft already, thanks. Should the descriptions for clientX and clientY mention that they are coordinates relative to the visual display being presented by the view given in the view attribute? I think they should yes. [getModifierState] I think it would be helpful for the description of this method to list all of the modifier keys that are listed in Appendix A, and also that others may be used for other modifiers. Is that really better than referring to App A? Lists that are copied over tend to go out of sync. There should also be a way to get a list of all of the modifiers that are in effect, so that applications can make use of modifiers that aren't listed in Appendix A. Applications can already make use of any modifier not listed by the specification. I don't feel very strongly about this but I'm not sure what the value would be of having a way to list all modifiers that are in effect. All you could do with it is get a list of modifiers which you know about and therefore could also query, and of modifiers which you didn't know existed, and therefore can't do anything with. With initMouseEventNS, what happens if a key that is not a modifier is given in the modifiersList argument, such as Tab? What if it specifies a key that the implementation does not know about? I would think that a key that isn't a known modifier counts as an unknown modifier (I don't see it being interpreted as a key), and any random string that does not contain a space is currently considered to be a valid modifier. I would expect the resulting event to carry around that unknown modifier and expose it through getModifierState(). * 1.8.5 Mutation and mutation name event types Are the DOMElementNameChanged and DOMAttributeNameChanged events fired if the renameNode just fell back to removing the node and adding a new one? My take would be that in order for authors to be able to expect reasonably consistent implementations, not only should they be dispatched in this case but the mutation events corresponding to the underlying removal/addition should not. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: ISSUE-76: Shoud window participate in event propagation
On Apr 13, 2006, at 01:29, Web APIs Issue Tracker wrote: Should we define if or how the Window objects participates in the event propagation? At least Firefox makes the Window object implement EventTarget and puts it above the Document node in the propagation chain. Yes, it should be defined (either way, I don't have a strong preference). Also, which spec should address this? The Window spec or DOM L3 Events? I think it's definitely something that would go in the Window spec. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
random notes on the XHR editorial notes
Hi, here are a few thoughts on the editorial notes that are in the draft. First: since editors seem to be liking ednotes, would folks see value in having ReSpec generate anchors for them so we could easily link to them? • What about non-ECMAScript implementations? I think Cameron's idea of having a createXHR() available to the languages that may need it could be useful indeed. • Need to define which IDL specification we are going to conform to, if any. This came up on xml-dev, where OMG IDL was blamed for the fact that we have createElement() and createElementNS() in the DOM instead of just one (there may be other reasons). I am all for forgetting about OMG IDL, but I think we need to consider the following: - some folks generate Java interfaces from the IDLs. I think we're safe so long as we generate a binding from what we have (which is easy to add to ReSpec, I can do it) - some implementations (Mozilla?) seem to use OMG IDL. Would they be fine with something else, or with hacking the something else themselves, or if we generated something more kosher and let them do whatever workaround they do to get around it for stuff they already support? - the stuff that's in the interface definition should be formal to some point. If we don't use OMG IDL, it would be really best if we defined whatever it is we use. We can keep it simple, but we might not be able to dodge writing a Note describing it. • What if languages don't have functions? Perhaps this should be an EventListener? What DOM 3 Events does currently is that in the Javascript binding it make EventListener be a Function (and doesn't give it the handleEvent field, which is debatable but would work well here). I think we should consider this option. • What about HEAD requests? This is worth a test of what current implementations do. Assuming a void it would be best to go to 3 once (so that we're always guaranteeing that 3 is touched at least once for any complete request, it makes scripting with it simpler), and hop immediately to 4. • What about PUT and DELETE? We were fairly agreed that these should be supported at the f2f, unless there is a good reason not to (e.g. current implementations skip them). In fact our resolution was that (again, unless we bumped into something during testing) all methods should be allowed, including the DAV ones which would be very cool for some uses, for instance CMS UIs. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: First Public WD of XMLHttpRequest released
On Apr 05, 2006, at 21:48, Jim Ley wrote: The responseXML MUST be null if the document is not WF cannot currently be relied on in implementations, do you want to highlight that fact? I think that we agreed that that behaviour was a bug and that we really should be encouraging null. I guess that flagging what implementations do might depend on how soon the bug is fixed. MUST for xmlEncoding seems unreasonably tight restriction, what's the motivation? Agreed. Immediately before processing the message body (if any), the readyState attribute MUST be set to to 3 (Receiving). Processing the message body is unclear - does that mean XML parsing it, or does that mean loading it or what? Actually, what we said at the f2f was immediately after having read the headers (i.e. hit the \n\n) which is simpler and also means that we have defined behaviour for HEAD and other disembodied, err, bodiless responses. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
Re: ISSUE-70: what to do about window timers?
Hi Maciej, On Apr 04, 2006, at 12:30, Web APIs Issue Tracker wrote: What to do about timers? Some rough options: A.1) Define in an ECMAScript-only way, and assume other languages all have their own built-in timer facility. But is that true? In particular, do they have one that is usable in a browser scripting context? I am not sure, since timer facilities are generally based on some sort of event loop, and the browser controls the event loop in this case. I think we have to standardise the ES timers as they are currently available in browsers. That's the only way in which they can ever get reused by other specs. If we don't do that they'll have to invent new stuff, which it is our task to make sure they have no reason to do. B.1) Invent a new timer API that's more like the SVG uDOM one (but simpler to use, it shouldn't take 4 lines of code to set up a timer callback in ES). Define the existing implemented Window timer methods in terms of this for ECMAScript only. That's already part of our deliverables, so I would expect that we stick to the plan. We have to stick to what exists because it's what most people will be used to having and will want (and what will get implemented) but we need something simple and new that works for other languages, and that may have the extra advantage here or there so that ES folks may perhaps actually want to use it when available. For extra points we should define the relationship between the two facilities. There is also the option of making it just like an EventListener, but I don't think events are a good model for timers firing, most toolkit APIs I know of make timers and events separate concepts. I quite like the idea of an event based model because one could then wire in timer events into the rest of the system, such that it would work with SMIL, XML Events, etc.. I'm not married to it, but I like it. The plan I had in mind was that I would dump what the SVG WG came up with into a spec, and put it up so that folks could start tearing it to pieces or falling in love with it (or both, if you're into that). I didn't have it up in high priority though, the FPWD is on the timeline in September (but we can be flexible about that). This is the one time in writing this spec I have felt the temptation to invent a new feature. Someone smack me back to reality. C'mon, hang in there, the better we stick to the documentation part of our jobs, the sooner we'll be able to get creative where needed ;) -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
