Re: Points of order on this WG
Hi, Arun- Arun Ranganathan wrote (on 6/25/09 1:38 AM): On Jun 23, 2009, at 5:10 PM, Ian Hickson wrote: The Web Storage specification is someone dead-locked right now due to the lack of consensus on whether to use SQL or not. This topic continues to be discussed in Mozilla newsgroups. Few are reconciled to SQL usage: Example: http://groups.google.com/group/mozilla.community.web-standards/topics Solutions such as BrowserCouch (which straddles localStorage currently) offer other options: http://www.toolness.com/wp/?p=580 I'd personally rather see a clear articulation of use cases that we agree are important for the web than further specification work. Actually, I think that's an excellent point. Nikunj, maybe that is the next logical step? Could you take charge of that? Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Points of order on this WG
On Thu, 25 Jun 2009, Doug Schepers wrote: On Jun 23, 2009, at 5:10 PM, Ian Hickson wrote: The Web Storage specification is someone dead-locked right now due to the lack of consensus on whether to use SQL or not. I don't buy this argument for an instant, and I'd be very surprised if anyone in the WebApps WG did. This specification was published as specified because it matched the behavior (more or less) of an implementation (WebKit), and it's disingenuous to pretend that that doesn't set a precedent for the future development of the specification. Let's be frank: there is good reason to specify and standardize something that exists in a browser, because there is implementation experience, and opportunity for widespread adoption, which is often good; this is especially so with an implementation in a widespread open-source engine like WebKit, because it can be reused. I don't find fault with that premise. But just because it's been implemented doesn't mean it's the correct or best (or even a good) solution. There is less justification for insisting on a single solution when it's only been implemented in one browser engine, and only just recently. There's little evidence that this will work well for other implementers, nor that this is the solution that works best for content developers. I cannot take seriously a claim that a spec can't be changed due to a lack of consensus when the claimant has openly and repeatedly indicated a disinterest in consensus. So, the only conclusion I can draw is that the spec is currently in a holding pattern to allow the currently specified solution to gain defacto weight through real-world content, and possibly garner premature implementations before it is even in LC, thus making it all but impossible to change. As Kyle Weems put it: Deny, Delay, Too Late. I think there may have been some misunderstanding about what I said above (possibly because of my typo; s/someone/somewhat/). When I say that the Web Storage spec is deadlocked, I mean that as it stands, it isn't acceptable, since it doesn't represent what at least one major vendor (Mozilla) wants, but that there haven't been any alternative proposals that have gained widespread approval either, and so I don't know how to move the spec forward. (I've been working with Mozilla off-line to try to resolve this, but do not yet have a solution.) There is no attempt on my part to force anything through de-facto implementations; it is in fact the lack of vendors willing to implement what is in the spec that is keeping it in a holding pattern. There is no claim that Web Storage can't be changed; indeed, I claim that it _must_ be changed, it's just that I'm not sure what it should be changed _to_. In any case, adding a new feature to a spec whose future is uncertain isn't a good idea because it means that the new feature's progress is tied to the uncertain future of the rest of the spec. Thus, my recommendation to Nikunj would be to create a new WG deliverable, not one tied to the fate of the SQL Database section. Nikunj has asked that his proposal be given equal weight and consideration. While I'm not sure that's possible even now, because of the existing implementation, I personally think it is reasonable to give him a platform to demonstrate the relative merits of his alternate proposal. I think Nikunj's proposal definitely is worthy of being persued, just like the working group is persuing dozens of other proposals like XHR, CORS, Selectors API, Workers, Server-Sent Events, Web Sockets, etc. I don't believe it really fits into the Web Storage spec (if anything, I think we should split Web Storage into two further specs, not add a third wholly independent feature to it). However, I would definitely support an FPWD publication of Nikunj's proposal, as I have for other proposals. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Do we need to rename the Origin header?
On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote: On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) To make it clear what the intent is here: We know that people are building web applications where GET requests cause state changes on the server side. While this is unfortunate, we don't believe that people will stop. Thus we sometimes want Sec-From to be included in GET requests. At the same time, it's a quite common practice on the web today for sites to allow other users to put a href=... links on their site. For example discussion boards often detect addresses and turn them into links, some, such as wikipedia, even allow users to hide which url the link is going to by specifying an arbitrary text for the link. In these cases we don't want the person inserting the link to be able to speak for the site the link was located on. Additionally, one of the reasons why the referer (sic) header is being so frequently blocked is that it leaks information about where users are coming from. For example when a political website linking to google.com it has bothered many users that this tells google my political affiliation, causing them to filter the referer header. Thus in these two cases we don't want the GET request to include a Sec-From header containing the originating website. The difference between these two cases is purely in the context from which the GET request was created. While we could enumerate these contexts in Adams spec, IETF has in the past expressed a dislike for specifying application behavior, prefering only to define protocol behavior. Thus we have to define the protocol in an IETF spec, and allow HTML5 (or some other spec) to selectively invoke the different behaviors defined by the IETF spec. / Jonas
Re: Handling too few arguments in method calls
Cameron McCormack:
From some very brief testing, it seems that Firefox and Opera tend
to throw an exception when calling a method with too few arguments,
while IE, Safari and Chrome will assume that the missing arguments
were the undefined value.
Simon Pieters:
Hmm. What did you use as test case?
I did calls like:
HTMLCollection.item()
HTMLCollection.namedItem()
HTMLDocument.getElementsByName()
HTMLDocument.getElementsByClassName()
Document.getElementById()
Document.createTextNode()
making sure I could distinguish between that behviour and the behaviour
I’d get if calling with (undefined).
I think I prefer option 2. It's easier for authors to find their mistake.
If a spec author wants the behavior of option 1, then that's possible
with [Optional].
I tend to prefer option 2, as well, for those reasons, plus it might
help us if we introduce new overloadeded operations later. For example,
if we had
interface A {
/* f1 */ void f();
/* f2 */ void f(in boolean x, in boolean y, in boolean z);
};
and authors were calling A.f(something) and getting f2, then it might
make it harder for us to introduce
void f(in boolean w);
or even
void f(in DOMString w);
later on.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: Do we need to rename the Origin header?
On Thu, 25 Jun 2009 05:50:32 +0200, Bil Corry b...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? HTML5 defines an XHTML serialization too. (Which is also the XHTML UAs implement.) Keeping the behavior of the two serializations as similar as possible is a goal of the HTML5 effort so this should not happen. -- Anne van Kesteren http://annevankesteren.nl/
[WebIDL] Callback, PropertyOnly, NoInterfaceObject
Hi Cameron,
Following our conversation on the geolocation ML
http://lists.w3.org/Archives/Public/public-geolocation/2009Jun/0173.html
I have the following clarification request related to the Web IDL spec.
In the geolocation spec we have now:
[NoInterfaceObject]
interface PositionOptions {
attribute boolean enableHighAccuracy;
attribute long timeout;
attribute long maximumAge;
};
Proposed and agreed in our mail discussion:
[Callback]
interface PositionOptions {
attribute boolean enableHighAccuracy;
attribute long timeout;
attribute long maximumAge;
};
Our intentions are:
1) Not to instantiate the interface object with new PositionOptions();
This is handled by not specifying [Constructor] extended attribute.
2) Not to have PositionOptions on the ES global object.
This shall be handled by specifying [NoInterfaceObject]. But it seems to have
to be removed.
3) Use PositionOptions interface to specify properties of the object passed to
e.g. getCurrentPosition() method.
This is handled by specifying [Callback].
4) Resulting from the above, use the PositionOptions as follows:
navigator.geolocation.getCurrentPosition(successCallback,
errorCallback,
{maximumAge:60});
Questions:
a) What is the PropertyOnly argument/identifier for?
It seems unclear from the Web IDL spec.
Does it specify that the interface has one attribute only and ES binding just
one property?
Or does it specify that the interface includes only attributes?
Or does it signify only the opposite to FunctionOnly?
b)
Shouldn't we have the PositionOptions specified as follows?
[NoInterfaceObject]
[Callback=PropertyOnly]
interface PositionOptions {
attribute boolean enableHighAccuracy;
attribute long timeout;
attribute long maximumAge;
};
Thanks.
Marcin
Marcin Hanclik
ACCESS Systems Germany GmbH
Tel: +49-208-8290-6452 | Fax: +49-208-8290-6465
Mobile: +49-163-8290-646
E-Mail: marcin.hanc...@access-company.com
Access Systems Germany GmbH
Essener Strasse 5 | D-46047 Oberhausen
HRB 13548 Amtsgericht Duisburg
Geschaeftsfuehrer: Michel Piquemal, Tomonori Watanabe, Yusuke Kanda
www.access-company.com
CONFIDENTIALITY NOTICE
This e-mail and any attachments hereto may contain information that is
privileged or confidential, and is intended for use only by the
individual or entity to which it is addressed. Any disclosure, copying or
distribution of the information by anyone else is strictly prohibited.
If you have received this document in error, please notify us promptly by
responding to this e-mail. Thank you.
[widgets] dig sig RelaxNG schema
Using http://bondi.omtp.org/1.0/security/xmldsig-core-schema.rnc and
rnv [1] I've been trying to validate the example:
http://www.w3.org/TR/widgets-digsig/#example
Firstly does widgets-digsig have it's own grammar.rnc? I have not been
able to find one.
Using xmldsig-core-schema.rnc I ran into a couple of problems. Firstly
I had to alter:
Object.ANY = (element * {Object.ANY}|attribute * {text}|text)*
To accept the new elements introduced by
http://www.w3.org/TR/xmldsig-properties/
Also the xmldsig-core-schema.rnc seems sensitive to element order. So
I made a change to the rnc to get the example signature1.xml to
validate:
-Signature.attlist, SignedInfo, SignatureValue, KeyInfo?, Object*
+Signature.attlist, SignedInfo, Object*, SignatureValue, KeyInfo?
Or perhaps the order of the example is incorrect?
Be great to see more fully worked examples. An author-signature.xml
example would be good.
Kind regards,
[1] http://www.davidashen.net/rnv.html
Belated Regretts for telcon.
Last minute changes in schedule prevented me from attending. Sorry for late regretts. Andy
Re: Do we need to rename the Origin header?
Jonas Sicking wrote on 6/25/2009 2:11 AM: On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote: On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) To make it clear what the intent is here: We know that people are building web applications where GET requests cause state changes on the server side. While this is unfortunate, we don't believe that people will stop. Thus we sometimes want Sec-From to be included in GET requests. At the same time, it's a quite common practice on the web today for sites to allow other users to put a href=... links on their site. For example discussion boards often detect addresses and turn them into links, some, such as wikipedia, even allow users to hide which url the link is going to by specifying an arbitrary text for the link. In these cases we don't want the person inserting the link to be able to speak for the site the link was located on. Additionally, one of the reasons why the referer (sic) header is being so frequently blocked is that it leaks information about where users are coming from. For example when a political website linking to google.com it has bothered many users that this tells google my political affiliation, causing them to filter the referer header. Thus in these two cases we don't want the GET request to include a Sec-From header containing the originating website. The difference between these two cases is purely in the context from which the GET request was created. While we could enumerate these contexts in Adams spec, IETF has in the past expressed a dislike for specifying application behavior, prefering only to define protocol behavior. Thus we have to define the protocol in an IETF spec, and allow HTML5 (or some other spec) to selectively invoke the different behaviors defined by the IETF spec. Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). - Bil
Re: Points of order on this WG
Nikunj, All, Charles will respond separately regarding a way forward but I want to respond to the false accusation below. On Jun 24, 2009, at 8:13 PM, ext Nikunj R. Mehta wrote: The WG chair went ahead with the publication of the Web Storage draft overriding serious objections about it's direction and emphasis. The record actually shows Nikunj saying: [[ http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0145.html Oracle conditionally supports the publishing this draft as FPWD provided that the abstract is worded appropriately. ... Here's what Oracle would like to see in the abstract: This specification defines two APIs for persistent data storage in Web clients: one for accessing key-value pair data and another for accessing structured data. ]] Ian agreed [1] to make the requested change above (it is included in the FPWD [2]) and thus addressed the only concern you raised re publishing the FPWD. -Regards, Art Barstow [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0149.html [2] http://www.w3.org/TR/2009/WD-webstorage-20090423/
Re: [widgets] Draft Minutes from 25 June 2009 Voice Conference
On Jun 25, 2009, at 10:16 AM, Barstow Art (Nokia-CIC/Boston) wrote: The draft minutes from the June 25 Widgets Security voice conference are available at the following and copied below: http://www.w3.org/2009/05/25-wam-minutes.html The correct URI is: http://www.w3.org/2009/06/25-wam-minutes.html -Regards, Art Barstow
Re: Handling too few arguments in method calls
What about too many arguments, and ignoring extra ones? Is that settled? -- Darin
Re: Points of order on this WG
I have listed these requirements on my blog - http://o-micron.blogspot.com/2009/06/requirements-for-and-components-needed.html I will put these together in a forma suitable for W3C uses. Nikunj http://o-micron.blogspot.com On Jun 24, 2009, at 11:13 PM, Doug Schepers wrote: Hi, Arun- Arun Ranganathan wrote (on 6/25/09 1:38 AM): On Jun 23, 2009, at 5:10 PM, Ian Hickson wrote: The Web Storage specification is someone dead-locked right now due to the lack of consensus on whether to use SQL or not. This topic continues to be discussed in Mozilla newsgroups. Few are reconciled to SQL usage: Example: http://groups.google.com/group/mozilla.community.web-standards/topics Solutions such as BrowserCouch (which straddles localStorage currently) offer other options: http://www.toolness.com/wp/?p=580 I'd personally rather see a clear articulation of use cases that we agree are important for the web than further specification work. Actually, I think that's an excellent point. Nikunj, maybe that is the next logical step? Could you take charge of that? Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs
Re: Points of order on this WG
On Jun 24, 2009, at 7:34 PM, Michael(tm) Smith wrote: Nikunj R. Mehta nikunj.me...@oracle.com, 2009-06-24 17:13 -0700: I want to raise two formal points of order about the manner in which this WG has operated, particularly in respect to Web Storage. 1. Charter 2. Process Firstly, no one seriously responds to proposals about things that are officially in the WG's charter. That's not true. If you believe that's been the case with a specific proposal, then let's please talk about that specific proposal instead of turning this into a process discussion. Please look to the bottom of my original email to see why this became a process discussion. If my interpretation is incorrect, please explain in the context of the specific details there instead of simply saying it is not true. If there is inadequate interest, then we should get rid of the responsibility from this WG's charter. If there's inadequate interest in *a particular proposal* from other members of the group -- particularly among the vendors who would be expected to implement it -- then that would be a pretty good indicator that an investment of the already-constrained resources of the group into trying harder to move that the proposal forward might not be an investment that's likely to pay off for us well as a group (in terms of actually being successful at getting it implemented in UAs). 1. Oracle provided use cases and requirements [1] around storage in Web browsers. 2. Oracle submitted a proposal first in October [2]. 3. The WG's charter was changed and deliverables added without an open process [3]. 4. Oracle revised its proposal in April [4] based on limited feedback on public-webapps. Oracle has also implemented this proposal in a browser plug-in for Safari and Firefox before submitting this proposal. 5. This WG provided two very brief sets of questions. I responded to both sets of questions without any delay, and assumed that the questions were answered. Of these one was simply asking me to go to HTML5 without attempting to address any of the requirements identified in [2] or the technical details of the revised proposal [4]. 6. Then I asked for permission to add to the Web Storage draft, and was told that my proposal did not belong there, without any explanation. On the other hand, there were no documented requirements for Web Storage (and most likely for other Web* FPWDs) until I asked for it. Even then all I get is one requirement at least be as useful as SQL [4a]. There has been reluctance to support for the current Web Storage draft's SQL mission in popular browsers. It is evident from [5], [6], and [7] and still we are consuming this WG's precious time for that proposal. The policy of this group is to interpret silence as assent, isn't it. By that token, browser vendor members of this WG have have supported Oracle's current proposal because no one has said that implementing this spec is not in their and/or the Web's interest. On the other hand, if Web Storage and related matters are in this WG's charter based on this WG's agreement, there should be feedback from its members, As far as I can see, that's already happening. Not true in the case of Oracle's proposals. and at least substantive discussions by its appointed editors. First off, Ian is not an appointed editor for the Web Storage draft. He's the editor of that particular draft by virtue of the fact that he's the one wrote it. But the fact that he wrote it and contributed it to the group does not magically bless it nor necessarily give it any position of special entitlement in the group. If you or any other member wants to contribute a related or alternative draft and check it into the group's document repository, you are very much encouraged to do so. We can then continue with discussion about it -- with a status of Editor's Draft in the group -- up to the point where we decide if/when we decide as a group that we want to transition it to a First Public Working Draft. Let's see how this process works in practice. W3C is setting up a CVS account for me as we speak. Nikunj http://o-micron.blogspot.com [1] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0104.html [2] http://lists.w3.org/Archives/Public/public-webapps/2008OctDec/0130.html [3] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0251.html [4] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0341.html [4a] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0303.html [5] http://groups.google.com/group/mozilla.community.web-standards/msg/d6a92db27bd52bcb [6] http://groups.google.com/group/mozilla.community.web-standards/browse_frm/thread/da7000dcc486c0fb
Re: Points of order on this WG
On Jun 24, 2009, at 10:24 PM, Doug Schepers wrote: Hi, Nikunj- I think Mike was overly blunt, but essentially correct in his response, but I'd like to add a specific comment inline... Nikunj R. Mehta wrote (on 6/24/09 8:13 PM): On Jun 23, 2009, at 5:10 PM, Ian Hickson wrote: The Web Storage specification is someone dead-locked right now due to the lack of consensus on whether to use SQL or not. snip As Kyle Weems put it: Deny, Delay, Too Late. snip I would endorse you, Nikunj, to edit the Web Storage spec to include your proposal. However, I will also say that the burden of proving that your solution is better lies on you. I'm not going to pretend this is not an uphill battle. If you or someone on the Oracle team wants to demonstrate an implementation of your proposal, or even better, contribute that code to the WebKit or Mozilla codebase, that would be a compelling way of demonstrating relative merits... cutting-edge authors could experiment with both and provide feedback about what aspects of each they prefer. That would be an effective argument in favor of one or the other. You bet. I will say that Hixie's proposal (which, if I understand it, comes from Apple's implementation) has an advantage, because he has been working within W3C and directly with browser vendors for a while; he knows how to write specifications in the style that implementers prefer, and he also has their respect on technical matters. You would do well to specify your proposal in a manner similar to his, with similar detail, and to cultivate credibility and relationships with browser vendors if you want to gain preference for your proposal. I'm sorry this is not the most encouraging statement, but I believe it is factual, and it is intended as helpful advice. No worries.
Re: [widgets] dig sig RelaxNG schema
Kai
XML Signature 1.1 is specified using XML Schema [1]. XML Signature
1.1 has a draft RNG schema [2]. We did not develop an rnc grammar for
widget signature.
The XML Security WG started to work on an XML Signature 1.1 RNG schema
[2] but since we do not have deep expertise in the group we have not
progressed this yet. However the tests from XML Signature Second
Edition validated against it. We received some feedback about using
different styles of RNG schema authoring which we do not have much
expertise in the group to process - If you are able to help get the
schema correct that would be helpful. It is on our list of things to
do to attempt to improve it, if we can get help.
Is having RNG/RNC schema important? Can you or someone in the WebApps
working group please help, perhaps by reviewing our RNG schema
document and suggesting improvements?
I'm copying this message with the XML Security WG.
Thanks
regards, Frederick
Frederick Hirsch, Nokia
Chair XML Security WG
[1] http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/Overview.htm#sec-Schema
[2] http://www.w3.org/2007/xmlsec/Drafts/xmldsig-rngschema/
On Jun 25, 2009, at 7:13 AM, ext Kai Hendry wrote:
Using http://bondi.omtp.org/1.0/security/xmldsig-core-schema.rnc and
rnv [1] I've been trying to validate the example:
http://www.w3.org/TR/widgets-digsig/#example
Firstly does widgets-digsig have it's own grammar.rnc? I have not been
able to find one.
Using xmldsig-core-schema.rnc I ran into a couple of problems. Firstly
I had to alter:
Object.ANY = (element * {Object.ANY}|attribute * {text}|text)*
To accept the new elements introduced by
http://www.w3.org/TR/xmldsig-properties/
Also the xmldsig-core-schema.rnc seems sensitive to element order. So
I made a change to the rnc to get the example signature1.xml to
validate:
-Signature.attlist, SignedInfo, SignatureValue, KeyInfo?, Object*
+Signature.attlist, SignedInfo, Object*, SignatureValue, KeyInfo?
Or perhaps the order of the example is incorrect?
Be great to see more fully worked examples. An author-signature.xml
example would be good.
Kind regards,
[1] http://www.davidashen.net/rnv.html
Re: Points of order on this WG
On Jun 25, 2009, at 9:34 AM, Arthur Barstow wrote: Nikunj, All, Charles will respond separately regarding a way forward but I want to respond to the false accusation below. On Jun 24, 2009, at 8:13 PM, ext Nikunj R. Mehta wrote: The WG chair went ahead with the publication of the Web Storage draft overriding serious objections about it's direction and emphasis. The record actually shows Nikunj saying: [[ http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/ 0145.html Oracle conditionally supports the publishing this draft as FPWD provided that the abstract is worded appropriately. ... Here's what Oracle would like to see in the abstract: This specification defines two APIs for persistent data storage in Web clients: one for accessing key-value pair data and another for accessing structured data. ]] Ian agreed [1] to make the requested change above (it is included in the FPWD [2]) and thus addressed the only concern you raised re publishing the FPWD. Seeing the way things were, there was no way to stop the publication [1]. To mitigate the negative effects of publication, Oracle made its assent conditional. In reality, the chairs should have taken in to account the prior reluctance to continue with the draft [2] and asked the author to seek requirements and provide cautionary text in prominent places in the FPWD. [1] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0143.html [2] http://lists.w3.org/Archives/Public/public-webapps/2009AprJun/0106.html
Re: Do we need to rename the Origin header?
On Thu, Jun 25, 2009 at 8:10 AM, Bil Corryb...@corry.biz wrote: Jonas Sicking wrote on 6/25/2009 2:11 AM: On Wed, Jun 24, 2009 at 8:57 PM, Adam Barthw...@adambarth.com wrote: On Wed, Jun 24, 2009 at 8:50 PM, Bil Corryb...@corry.biz wrote: Continuing your example, if XHTML defines requests from form as privacy-sensitive, then the UA will have two different behaviors for Sec-From, depending on if it's rendering HTML5 or XHTML? That's correct. Hopefully folks writing specs at the application layer will coordinate so as not to make the web platform any more confusing than it is already. :) To make it clear what the intent is here: We know that people are building web applications where GET requests cause state changes on the server side. While this is unfortunate, we don't believe that people will stop. Thus we sometimes want Sec-From to be included in GET requests. At the same time, it's a quite common practice on the web today for sites to allow other users to put a href=... links on their site. For example discussion boards often detect addresses and turn them into links, some, such as wikipedia, even allow users to hide which url the link is going to by specifying an arbitrary text for the link. In these cases we don't want the person inserting the link to be able to speak for the site the link was located on. Additionally, one of the reasons why the referer (sic) header is being so frequently blocked is that it leaks information about where users are coming from. For example when a political website linking to google.com it has bothered many users that this tells google my political affiliation, causing them to filter the referer header. Thus in these two cases we don't want the GET request to include a Sec-From header containing the originating website. The difference between these two cases is purely in the context from which the GET request was created. While we could enumerate these contexts in Adams spec, IETF has in the past expressed a dislike for specifying application behavior, prefering only to define protocol behavior. Thus we have to define the protocol in an IETF spec, and allow HTML5 (or some other spec) to selectively invoke the different behaviors defined by the IETF spec. Thanks for the clarification. Will there be some mechanism within HTML5 to denote links that are privacy-sensitive versus those that are not? I'm imagining that by default, links to external resources would be considered private unless denoted as public (non-private?). This is still being debated. But lets do that in a separate thread. / Jonas
Re: Points of order on this WG
On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote: In any case, adding a new feature to a spec whose future is uncertain isn't a good idea because it means that the new feature's progress is tied to the uncertain future of the rest of the spec. Thus, my recommendation to Nikunj would be to create a new WG deliverable, not one tied to the fate of the SQL Database section. [...] I think Nikunj's proposal definitely is worthy of being persued, just like the working group is persuing dozens of other proposals like XHR, CORS, Selectors API, Workers, Server-Sent Events, Web Sockets, etc. I don't believe it really fits into the Web Storage spec (if anything, I think we should split Web Storage into two further specs, not add a third wholly independent feature to it). However, I would definitely support an FPWD publication of Nikunj's proposal, as I have for other proposals. I strongly agree on these points. I would prefer to see SQL Storage split out of the rest of Web Storage. We seem to have rough consensus and strong multilateral implementor interest on LocalStorage and SessionStorage, and they should be allowed to move forward on the standards track quickly. SQL Storage remains contentious, and only Apple and Google have shown strong implementor interest so far. And it has no technical tie to the other storage drafts. I also think Nikunj's proposal should be yet a third separate orthogonal draft. Regards, Maciej
Re: Points of order on this WG
On Jun 25, 2009, at 12:42 PM, Nikunj R. Mehta wrote: I think Nikunj's proposal definitely is worthy of being persued, just like the working group is persuing dozens of other proposals like XHR, CORS, Selectors API, Workers, Server-Sent Events, Web Sockets, etc. I don't believe it really fits into the Web Storage spec (if anything, I think we should split Web Storage into two further specs, not add a third wholly independent feature to it). However, I would definitely support an FPWD publication of Nikunj's proposal, as I have for other proposals. That is encouraging. I will be glad to edit an FPWD that includes B- tree, interception, and programmable cache, if the WG so prefers. It seems to me that Berkley DB style database storage, and request interception / programmable cache are orthogonal ideas and should arguably be separate drafts. I would assume request interception and programmable cache are usable regardless of what client-side storage APIs are available, much as HTML5 Application Cache is independent of these APIs. If anything, it seems more closely related to AppCache than to any proposed storage solution. Regards, Maciej
Re: Points of order on this WG
On Thu, Jun 25, 2009 at 12:42 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote: I have proposed to Mozilla a solution that provides access to an organized key-value database such as that provided in the (open source) Berkeley DB. In essence, a database is a simple B-tree - it keeps keys sorted and permits duplicate keys. It is able to find a key or a key prefix, which enables efficient searching through a very large number of items. If we are ambitious (i.e., need more functionality), we can add indexes and joins to this spec. There is unlikely to be an interoperability nightmare, such as that which is the most likely outcome with SQL, it does not mandate the use of any query language, and there is at least 40 years of experience with it, including in highly resource-constrained environments. (There are 200 million copies of Berkeley DB in deployment [1]). This is what so far seems like the best solution to me. I.e. something that is more backend-ish than what a SQL API would be. I'd love to see something that allows you to implement a SQL API on top of. But that also allows you to implement something like MungoDB very effectively. I think Nikunj's proposal definitely is worthy of being persued, just like the working group is persuing dozens of other proposals like XHR, CORS, Selectors API, Workers, Server-Sent Events, Web Sockets, etc. I don't believe it really fits into the Web Storage spec (if anything, I think we should split Web Storage into two further specs, not add a third wholly independent feature to it). However, I would definitely support an FPWD publication of Nikunj's proposal, as I have for other proposals. That is encouraging. I will be glad to edit an FPWD that includes B-tree, interception, and programmable cache, if the WG so prefers. What I don't understand is, why does interception (I assume you mean HTTP interception?) and programmable cache, belong in the same spec as a B-tree? / Jonas
Re: Handling too few arguments in method calls
Aaron Boodman:
But there is also an issue of legacy code. I brought this issue up in
a webkit bug awhile ago, and one concern from the webkit developers
was that introducing an exception would almost certainly break
sites. My opinion is that those sites are almost certainly already
broken.
I would worry about that, too. The amount of brokenness it experiences
because of a change to using exceptions could be far greater than it is
currently.
As a simple example, consider the setAttribute() method. Both
arguments are required, but in WebKit, if you don't pass either value
it is coerced to string. So if we take a simple attribute like
title:
someElement.setAttribute(title); // throws in Firefox, sets title
to undefined' in WebKit
Philosophically, I want to say that pages that are passing too few
arguments to DOM APIs are already broken, just in less obvious ways.
Breaking in more obvious ways would be better.
So we could change this to be:
interface Element {
void setAttribute(in DOMString name, [Optional] in DOMString value);
…
};
to keep setAttribute(title) working, but I think making the
optionalness of the argument to other language bindings in this case
isn’t a good idea. Also in this particular case it doesn’t seem like it
would be needed for web compatibility, if Firefox and Opera can get away
with throwing here.
If there’s a real need to allow some arguments on particular operations
in ECMAScript to be optional, and coerced from an undefined value, then
we can introduce an ECMAScript-specific extended attribute that permits
this. But in general I agree that it would be better if we could remain
strict.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: Handling too few arguments in method calls
Darin Adler:
What about too many arguments, and ignoring extra ones? Is that
settled?
It seems consistent with current implementations to ignore extra
arguments. That approach might go against the desire to maximise the
freedom API designers have to add additional overloaded operations
later, though. If we had
interface A {
void f();
};
and for whatever reason authors sometimes called it with an argument,
then it might make it harder to update the interface to
interface A {
void f();
void f(in float x);
};
later on. I have no idea how common it is for authors to pass too many
arguments to web APIs.
--
Cameron McCormack ≝ http://mcc.id.au/
Re: Handling too few arguments in method calls
Oliver Hunt: There's also overloaded functions like (for example) CanvasRenderingContext2d.drawImage void drawImage(in HTMLImageElement image, in float dx, in float dy, [Optional] in float dw, in float dh) if I do drawImage(image, x, y, foo) is this under-provision for drawImage(image,x,y,foo,undefined) or over provision for drawImage(image,x,y) or is it an error? Currently, passing a number of arguments (4) in between the allowed numbers (3 5) gives a TypeError. I’d be inclined to consider these cases as under-provision. Do we need an annotation to say something like void drawImage(in HTMLImageElement image, in float dx, in float dy, [Optional 2] in float dw, in float dh) (or something) that would say the next 2 arguments are optional, but both must be provided? Well, maybe. [Optional] actually means the argument it appears on and all following, as a group, can be omitted. I think this is a little confusing, though, so I’m thinking about allowing [Optional] only if it is the last argument, or if all following arguments are [Optional] (or [Variadic]). For other cases, like drawImage() here, you can use explicit overloading: void drawImage(in HTMLImageElement image, in float dx, in float dy); void drawImage(in HTMLImageElement image, in float dx, in float dy, in float dw, in float dh); -- Cameron McCormack ≝ http://mcc.id.au/
Re: Points of order on this WG
On Jun 25, 2009, at 5:23 PM, Jonas Sicking wrote: On Thu, Jun 25, 2009 at 12:42 PM, Nikunj R. Mehtanikunj.me...@oracle.com wrote: On Jun 24, 2009, at 11:35 PM, Ian Hickson wrote: I have proposed to Mozilla a solution that provides access to an organized key-value database such as that provided in the (open source) Berkeley DB. In essence, a database is a simple B-tree - it keeps keys sorted and permits duplicate keys. It is able to find a key or a key prefix, which enables efficient searching through a very large number of items. If we are ambitious (i.e., need more functionality), we can add indexes and joins to this spec. There is unlikely to be an interoperability nightmare, such as that which is the most likely outcome with SQL, it does not mandate the use of any query language, and there is at least 40 years of experience with it, including in highly resource-constrained environments. (There are 200 million copies of Berkeley DB in deployment [1]). This is what so far seems like the best solution to me. I.e. something that is more backend-ish than what a SQL API would be. I'd love to see something that allows you to implement a SQL API on top of. But that also allows you to implement something like MungoDB very effectively. I doubt you can efficiently or correctly implement SQL on top of a Berkeley-DB-style API. As a side note, it should be noted Berkeley DB itself could not be used by WebKit or Gecko to implement the spec, because even though it is open source, the license is not compatible with the LGPL. It seems unlikely that non-open-source browser engines could use it either, unless they are willing to pay Oracle for a commercial license. So it's very important for the spec to be clear and detailed, because everyone will have to implement it from scratch. It's also not clear to me if a BDB-level API is sufficient for developer needs. As I understand it, it's basically a giant dictionary with unstructured keys and values. So it's not providing much over LocalStorage, except for prefix matching and the ability to hold large amounts of records or records that are individually large. There's no way to efficiently query by one of several fields, as I understand it. Regards, Maciej
